#ByPassInterceptor
annotation is removed from seam 3 that i know .
and as per CDI documentation ,
By default, a bean archive has no enabled interceptors bound via interceptor bindings.
so is it safe if i remove #BypassInterceptor annotation from project while migration from seam2 to seam 3 ?????
are there no default interceptors in seam 3 ??
i would appreciate an answer .
Thanks
Yep, you can safely remove those. The design between Seam 2 and CDI is completely different. If you don't want interceptors run either remove it from the beans.xml or the class.
Related
This question already has an answer here:
What is the use of faces-config.xml in JSF 2?
(1 answer)
Closed 4 years ago.
I have been studying JavaEE8 and practicing with some projects, understanding the new technologies like Servlet 4.0 and JSF 2.3. I have read in many forums and pages, in some I see that they say that web.xml and faces-config.xml are not necessary, because annotations are now used, but in some others they continue to use them.
In which cases should you continue to use the Web Deployment Descriptor-> web.xml and the application configuration resource file-> faces-config.xml?
They aren't required, but I'd highly recommend to use them since you'll need them sooner or later for additional configuration anyways.
The annotations are used to achieve better readability and to simplify the faces-config.xml and web.xml, however they do not even nearly allow for the configuration options that can be made in the configuration files.
For example you can use the #FacesValidator Annotation instead of declaring and referencing the corresponding class in the faces-config.xml.
A task that can't be achieved by using annotations would be the declaratation of a welcome page. If you want to specify it, you need the web.xml.
I found a specific problem in the Mojarra implementation of JSF 2.3 when using the web.xml or faces-config.xml file. In the code of this implementation, the ELUtils class has the following condition:
if (getFacesConfigXmlVersion(facesContext).equals("2.3") || getWebXmlVersion(facesContext).equals("4.0")) {
throw new FacesException("Unable to find CDI BeanManager");
}
which throws an exception: "Unable to find CID BeanManager". I only had the faces-config.xml file with the latest version of JSF specified in the namespace and I was throwing that exception.
To avoid this problem, you can specify a different version of JSF (before 2.3) in the faces-config.xml file and specify a different version of the web.xml file (before 4.0), or simply do not add any of these configuration files. In my case, I removed the faces-config.xml and ran the application without problems.
I hope that the implementation of Mojarra will solve that little detail.
I have a problem when trying to use
#ManagedBean, it appears like this :
#ManagedBean,
Check the image below :
here is a photo of the code
Yesterday, I could create a project and use it, but today I cannot, I don't know what happened , maybe because I changed GlassFish 4 to 5 , and PostgreSQL 9.3 to 10?
EDIT: I tried to see my others project, and they are all stricken out in #ManagedBean.
The crossed line (aka "strikethrough") on a class, method, or annotation means that it has been deprecated by the author and you should no longer use it. If you mouse over the annotation, it should give you some sort of explanation as to why it was deprecated, and what you should use instead.
In this case, the JSF #ManagedBean annotation was "strongly discouraged" in JSF 2.2, and officially deprecated in JSF 2.3 (hence the strikethrough in your IDE). Instead, you should use the #Named annotation which is provided by CDI and is a more standard way of creating a bean in Java EE.
As i am now working on jsf i want to know why we use the tag verbatim in jsf and what is the significance of it ?
Any help would be of great appreciation.
Since you've tagged your question with jsf-2 the answer is: you shouldn't use it.
It is deprecated in JSF 2.0. It was a part of JSF 1.X and used to hold plain HTML. See also this answer, the docs (since 2.1 there is an additional info: The use of this element has been deprecated in Facelets for JSF 2.0 and beyond) and the usage example.
I'm going to upgrade Tomcat 6 to 7.
Currently in tomcat 6 I'm using different contexts with different Struts versions. 1 context uses struts 1 & another one uses Struts 2.
However, I'm merging contexts as ROOT.war in Tomcat 7. How to use Struts 1 & 2 in same war?
Also how to use the Struts2 security properties in the same WAR?
The Struts 1 servlet is only a servlet and can be configured in web.xml with a context. You can use different action extention to map servlet and struts2 filter, struts1 defaults to .do and struts2 defaults to .action. But if you want to map struts2 as /* then better to add an exclude pattern to struts2 configuration.
<struts>
<constant name="struts.action.excludePattern" value=".*\.do$"/>
...
</struts>
The value is regex pattern, you can try yourself, but the current expression will exclude everything that ends with .do.
when using CombinedResourceHandler in a Richfaces application only stylesheets and user defiend scripts are combined. The standard JavaScript resource and all Richfaces specific resources remain as seperated resources.
The Omnifaces documentation states:
RichFaces has the same problem with several JS files, but this is so far not exactly trivial to workaround
So my question is what this 'non-trivial workaround' would be?
As far as I can see, CombinedResourceHandler wont handle resources when getRendererType() returns org.richfaces.renderkit.ResourceLibraryRenderer. These are then handled by org.richfaces.renderkit.html.ResourceLibraryRenderer.
I am not sure what would be the best way to combine RichFaces behaviour with OmniFaces here.
I was able to create a solution by modifying OmniFaces CombinedResourceHandler.
Details in short:
Richfaces utilizes a concept called ResourceLibrarys wich means a resource may not only be a single file but instead a collection of those files. For example, RichFaces uses a resource named base-component.reslib. RichFaces ResourceHandler interpretes this resource dependency as dependency to
javax.faces:jsf.js
jquery.js
richfaces.js
richfaces-base-component.js
So the CombinedResourceHandler needed some extra functionality to seperate dependencies to ordinary Resources from Richfaces ResourceLibraries. The latter needed to be resolved according to specifications obtained from RichFaces sources.
It was not trivial to work this around without modifying the CombinedResourceHandler itself. The CombinedResourceHandler itself has really to be modified to use a reflection hack which extracts the resources from RichFaces' org.richfaces.resource.ResourceLibraryFactoryImpl. The reflection hack is necessary in order to keep OmniFaces free of RichFaces dependencies so that it can be used together with other component libraries like PrimeFaces.
As per issue 107, this was implemented in 1.3-20121206.