Many books list them under CDI (Context and Dependency Injection) but in the Java EE 7 API there are listed under different packages from the CDI
javax.decorator
javax.interceptor
See JSR-346 for the answer. You can find it here
Decorators are part of the CDI specification. You can find it in chapter 8.
Interceptors are not part of the CDI specification. It is referenced in 1.2.5 as a relationship to the CDI specification. It is part of the EJB specification JSR-345, see chapter 7 in that specification.
Related
Seeing as how there is a pretty cool XPage open source development community, I was wondering something. Are there any special conventions that we should be adhering to other than the java specific ones? I am referring to those regarding package names, class names etc.
To my knowledge, there aren't any really strong conventions among XPages development on top of the usual Java ones (name your packages after your DNS name, etc.). The only ones I can think of off the top of my head are minor and optional things, like using an "xsp" sub-package for frameworks/utilities that are XPage-specific (e.g. "com.ibm.xsp", "org.openntf.xsp", etc.). Beyond that, things are a conflicted mess, even just looking at what ships with XPages: some interfaces named "IFoo", some just "Foo"; some classes named "Foo", some "FooImpl", some "FooImplEx2".
In lieu of a community standard, I un-biased-ly advise you to adopt all of my personal conventions, as reflected in the frostillic.us framework and (mostly) the OpenNTF Domino API. So: no Hungarian notation, no "IFoo", no "FooImpl" (barring a compelling reason), Java code style similar to https://code.google.com/p/google-styleguide/source/browse/trunk/eclipse-java-google-style.xml , and final method parameters.
We name our java classes:
com.domain.whatever.Name
In faces-config I always want to capitalize my Managed Beans:
<managed-bean>
<managed-bean-name>CurrentJob</managed-bean-name>
<managed-bean-class>com.domain.inventory.Job</managed-bean-class>
<managed-bean-scope>session</managed-bean-scope>
</managed-bean>
That's all I have really. :)
I am learning to create custom JSF components and have been successful in creating simple ones. One thing I would like to know is that whether there are any naming conventions to be followed while defining <component-family> and <renderer-type> for your component?
For e.g. for combo box the <component-family> is javax.faces.SelectOne. It looks like a Java class but I was unable to find any such class in JSF API.
They do indeed not necessarily represent class names. They are just identifiers. The javax.faces prefix hints in this case merely that it's part of standard JSF API. The same prefix is used everywhere else in standard JSF API. PrimeFaces components use org.primefaces prefix, OmniFaces components use org.omnifaces prefix, etcetera.
You're fully free in choosing your own for your component library. You should only gurarantee that it shouldn't possibly conflict with a 3rd party one which may be mixed by the enduser. Like as with package structure of Java classes, it'd make sense if you choose for com.naveen prefix or whatever what/who represents the owner/developer of the component library.
The same approach as Java packages (and Internet domain names) is a very sensible way of guaranteeing uniqueness (you know, identifiers are supposed to be unique).
See also:
How do I determine the renderer of a built-in component
What is the relationship between component family, component type and renderer type?
Java packages com and org
This question already has answers here:
java.lang.IllegalStateException:Could not find backup for factory javax.faces.application.ApplicationFactory
(5 answers)
Closed 6 years ago.
I am trying to create a basic JSF 2.0 + Facelet application, but getting this error:
java.lang.IllegalStateException: Application was not properly initialized at startup, could not find Factory: javax.faces.application.ApplicationFactory
I am using following JARs:
jsf-impl-2.1.0
jsf-api-2.1.0
jstl-1.2
el-ri-1.2
Apache MyFaces 2.1.5
I am using following JARs
jsf-impl-2.1.0
jsf-api-2.1.0
Apache MyFaces 2.1.5
You seem to be mixing Mojarra and MyFaces implementations. This is not right. Use the one or the other, not both. The jsf-impl and jsf-api JARs are from Mojarra. Remove either them, or the MyFaces one. Mixing them will result in conflicts in finding the right implementation factories, exactly as the exception message is trying to tell you.
Further,
el-ri-1.2
this is supposed to be already provided by Tomcat. You're not supposed to supply your own. Remove it altogether.
All with all, given this pretty major mistake, I have the impression that you're not reading a proper tutorial/resource while learning JSF. I recommend to verify if this isn't just your own "stupid mistake", or if the resource really incorrectly said it so. In the latter case, consider looking for another one.
See also:
Our JSF wiki page - contains a Hello World and links to sane tutorials
requestScope is a com.sun.faces.context.RequestMap object, I found its methods reference at http://www.docjar.com/docs/api/com/sun/faces/context/RequestMap.html. I wonder if it belongs to the JSF API.
The packages here http://www.docjar.com/projects/Mojarra-2.0.1-code.html are different from the official reference here: download.oracle.com/docs/cd/E17802_01/j2ee/javaee/javaserverfaces/2.0/docs/api/index.html. It seems the packages have been moved into javax.*. So what version is XPage based on?
Erik Brooks has an article about this. Or take a look at the Wikipedia page.
XPages are based on JSF 1.2
I learned the answer after I knew more about J2EE. JSF API is only the specification. com.sun.faces.* and similar things are concrete implementations.
As a JSF 2/PrimeFaces developer I've had a look at Seam 3 as something that
could be useful in my project. So far the #RenderScoped functionality looks
interesting as a replacement for view scope and flash/page parameters, and
the catch module could be useful for more centralised exception handling. Are
there any other big ticket items in there that haven't immediately come to
my notice? I'm not quite convinced that it's worth investing in the time to
carry out a migration (much as I'm not similarly convinced about moving to
CDI from JSF managed bean annotations).
I hadn't exactly come across any literature that I would describe as a
summary.
Thanks,
O/S.
Well, you will have to read the documentation for yourself, but this is what I like about Seam 3 and what I am using:
Seam Solder (logger Injection, various annotations like #Veto, #Requires, resource-injection)
Seam I18N / Seam Faces (View Scopes, Message builder integration, automatic message conversion, handling & propagation of locales)
Seam Validation (bridging to Hibernate Validator which allows to use method-level validation (#AutoValidate of parameters / return values)
Seam Catch (you named it already)
Seam Mail (easy adoption of mailing functionality)
Seam Config (XML config of everything, extremely useful for Catch / Mail / etc)
Depending of the usecase, Seam Security and Seam Persistence might be just what you were looking for, same is true for Seam Rest.
There are various "Seam Modul spotlights" hiding at in.relation.to that are worth checking out...
I've tried so far security and i18n modules and they are great. Seam 3 is a really nice stuff to extend your toolbox. Highly recommended!