I was migrating my project from seam 2 to seam 3 .
In seam 2 we have #Expiration and #IntervalCron annotations but in seam-cron we don't have any such annotations. #scheduled is there but it's incomplete for my requirement.
I have gone through documentation but coudn't find any luck.
Is there any way to handle this?
I don't recommend to use Seam Cron, because the project is inactive and there won't be releases anymore. At least as far as I know.
So currently I recommend to use the scheduling functionality of EJB3 instead.
I'm not aware of any other CDI extension to provide such functionality.
The EJB3 schedule/timer/asynchronous is problematic when use the dependent EJB as CDI bean.
You can consider write a CDI extension for Cron like scheduling using Quartz, jaxenter.com provides an excellent tutorial for this.
http://jaxenter.com/tension-programming-42972.html
Related
I'm trying to move our application from an old JSF 2.2 version to JSF 3.0 (part of the Jakarta EE 9 platform). In the transition we want to replace the Mojarra implementation of JSF and want to replace it with the standard jakarta.faces-api. In the past we used explicit implementaions of JSF, servlet and other technologies, part of the Java EE specification. Now we want to use the standard-api approach.
I have a problem with a class that don't exist in the standard api but in the Mojarra implementation of JSF, the AbstractTagLibrary.
We use a Websphere-Liberty in the newest version, so with activated JSF features the application useses MyFaces.
What i tried so far was to replace the AbractTagLibrary with an own implementation. Bot i got an error that AbractTagLibrary should be of type org.apache.myfaces.view.facelets.tag.AbractTagLibrary.
The AbractTagLibrary is used to create custom EL functions. Like in this article.
My question is, how can i replace the AbstractTagLibrary with the standard jsf-api approach? Is there a good way to approach such a problem?
As BalusC said in his comment, the approach is JSF 1.x minded and can be solved by a JSF 2.0 approach explained here: https://stackoverflow.com/a/7080174.
I'm new in OSGI and I'm having many problems to try to create WABs. I'm using BndTools with Eclipse to help me with OSGi. My problem now is how can I integrate JSF with OSGi. I want to make one main web server, and add bundles with jsf pages runtime. How can I do this? What are the needs?
Thanks in Advance!
JSF is quite complex due to it's classloading mechanism. If you use Pax-Web you are able to use JSF, though it requires some special handling. For more details get in contact with the OPS4j community.
Another hint, since you seem to try to build your own "web-container", I don't recommend that, try to use an existing one, makes life easier :)
Currently, my web-application is based on the following libraries / frameworks / tools:
Java 1.6
JSF 1.2_07-b03-FCS
Facelets 1.1.14
Richfaces 3.3.2.GA
EL-Functors 1.0.2
Spring 2.5.2
Tomcat server v5.5
Some additional information:
Spring is in charge of managing all the beans used by JSF (org.springframework.web.jsf.DelegatingVariableResolver is defined as the variable-resolver in my faces-config.xml file).
EL-Functors is used as my el-resolver in order to extend the Expression Language.
I've created many custom components, some of them are just Facelets compositions, others are Java-based components (some of them are extending Richfaces components).
I want to try (essentially for curiosity, but if this works well, why not for real?) to migrate my application to JSF 2.0.
Question #1: what are the critical points that I must consider in order to make my application working correctly?
I am talking here about just having a working application, nothing less, nothing more.
I alread know that I will have to review all my custom components, because I will use the new version of Richfaces (4.0), and also see if they work correctly.
Question #2: what will be the first steps to achieve to take advantages of JSF 2.0?
Some ideas I already have are:
Remove EL-Functors and use the Expression Language 2.2;
Let JSF manage the beans, and use the #ManagedBean. Or maybe switch to a CDI library, such as Weld?
Use <f:ajax> instead of <a4j:support>?
Regarding JavaEE6
I know, a good idea would be to completely move to JavaEE6. I'd liked to do so, but for some reasons I just can't do that way. One (bad) reason is that I must stay on Tomcat servers.
However, I can add new third-party libraries in order to have some JavaEE6 features, such as EL 2.2...
So please consider this aspect in your answers.
Regards.
Since Richfaces 4 is still under development you may want to use Richfaces 3.3.3 with JSF 2.0.
Thus you have to use Facelets 1.1.15 as described here http://community.jboss.org/wiki/RichFaces333andJSF20
This implies that switching from a4j:support to f:ajax won't work with your Richfaces based components so I suggest to stick to a a4j:support. This will also keep the migration effort low if you decide to switch to Richfaces 4 as soon as it is available.
Since you already use Spring to manage your JSF-Beans there should be no need to use the DI-Features of JSF2. I'd stick to Spring but consider an update to Spring 3.
Besides this, Weld is definitley worth to take a look at.
HTH
If you plan to stay with Tomcat, then moving to Java EE 6 means you're going to be looking at Tomcat version 7.
But if you want a full-fledged Java EE 6 server then GlassFish 3 or JBoss 6 is a better alternative. Tomcat can be iffy when you try to do certain thing like CDI (Weld) or EJB 3.
Just my two cents worth. Hope it helps...
How can I configure jsf in openbravo? Is it possible?
If possible, could you guide me, since I am new to openbravo.
jBoss Seam integrates with Openbravo. Seam itself was brought to make easier integration of JSF with another technologies.
I am reading through the Public Review Draft of the Web Beans specification (JSR-299) and I am wondering why it is so 'tightly coupled' to JSF?
Especially the Conversation Context seems only be specified for JSF.
I understand, that it is a goal of WebBeans to integrate JSF and EJB3. But would it not make sense to specify the concept of conversations on a more general level (maybe for Servlets in general and not for a specific web framework)?
Is there any technical reason for this? I think it can hardly be, because Seam (which is some Kind of WebBeans-Prototype) does also support Wicket and provides the concept of conversations.
I think it would be helpful to have a Conversation Scope on Servlet level (injecting of conversation-scoped beans into servlets). In my understanding, this is not the case with the ciurrent specification (see chapter 8.5.4). Or am I misinterpreting something here ...
Just found this today. The reason why the ConversationScope is JSF based is simply because JSF is the standard UI framework for Java EE!
Beside this, most of the JSR-299 containers can provide Conversations for other UI technologies like e.g. Wicket too.
Otoh you can easily create your own Scopes which are even portable.
LieGrue,
strub
I think it's soley down to Gavin King picking JSF as his view technology for Seam and him pushing through the JSR as spec lead.
Clearly conversations go wider - for instance, Spring custom scopes have a facility for providing conversations:
http://static.springframework.org/spring/docs/2.5.x/api/org/springframework/beans/factory/config/Scope.html