Seam 3 and fork/join framework in JDK 7
by Arbi Sookazian
Hi all,
I just read this interesting article on fork/join frmwk by Ted Neward:
http://www.devx.com/SpecialReports/Article/40982
I'm wondering if there are any plans to use or recommend Seam 3 developers
to use the fork/join frmwk in Seam 3 if Seam 3 will run on JDK 7. I'm
guessing the final release dates for OpenJDK and Seam 3 may possibly be
around the same time (some time after June this year?)
Will Seam 3 be compatible with Java 7?
thx.
15 years, 11 months
hot deploy of individual beans in Seam 3
by Arbi Sookazian
"Seam 3 will offer hot deploy of individual beans to allow changes to made
to the bean signature without restarting the whole application. This
functionality is provided by reloading the class definition and then by
reloading the metadata for the class and bean. The details of how this will
work are pending."
http://seamframework.org/Documentation/Seam3Overview#H-HotdeployOfBeansLe...
Are we talking about JavaBeans only or JavaBeans and EJB components? What
about adding/removing methods in a class or the JRebel/Seam integration
effort?
15 years, 11 months
declaratively beginning a LRC in Seam 3
by Arbi Sookazian
I just was reading the code for one of the Seam 3 booking example classes (
http://anonsvn.jboss.org/repos/seam/examples/trunk/booking/ejb-jar/src/ma...
):
public
@Named("bookingAgent")
@Stateful
@ConversationScoped
class BookingAgentBean implements BookingAgent
{
private @Logger Log log;
@PersistenceContext(type = EXTENDED) EntityManager em;
@Inject Conversation conversation;
@Inject StatusMessages statusMessages;
@Inject BookingFormControls formControls;
@Registered User user;
//@Fires @Confirmed Event<BookingEvent> bookingConfirmedEvent;
@Inject BeanManager manager;
private Hotel hotelSelection;
private Booking booking;
private boolean bookingValid;
public void selectHotel(Hotel hotel)
{
// NOTE get a fresh reference that's managed by the conversational
persistence context
hotelSelection = em.find(Hotel.class, hotel.getId());
log.info("Selected the {0} in {1}", hotelSelection.getName(),
hotelSelection.getCity());
conversation.begin();
}
...
}
Note the programmatic use of beginning a LRC in the selectHotel() method
above (begin()). AFAIK, in CDI/Weld, we don't have the capability to
declaratively begin a LRC (like we do in Seam 2.x with @Begin) but can we do
something like write @Begin at method level in Seam 3 apps?
Also, is @ConversationScoped required if the component is @Stateful?
Conversation scope is current default for SFSBs in Seam 2.x.
I found the following example in the weld ref doc:
@ConversationScoped @Stateful
public class OrderBuilder {...}
15 years, 11 months
Seam 3 Development
by Ken Finnigan
Hi,
I'm currently starting a project in which I will be using Seam 3 and CDI.
I will need some aspects of Seam 2, such as security and
internationalisation, in Seam 3 to complete the full set of
functionality that I would require for my project. So that the security
and internationalisation Seam 3 modules can be released in the not too
distant future I would like to offer my assistance in the development of
these and possibly other modules in the future.
My previous experience of Seam 2 has been on hobby projects of my own,
as well as a share trading platform for an Australian investment bank.
Looking forward to being involved in the further development of Seam.
Thanks
Ken Finnigan
15 years, 12 months
XML Extensions
by Stuart Douglas
I have just commited my XML extensions to https://svn.jboss.org/repos/seam/modules/xml/trunk/ and I would like a bit of feedback on some of the changes I have made and would like make to the syntax specified in the original web beans spec. Details are below:
Syntax for producer beans (implemented)
The original spec used this syntax:
<ns:Bean>
<ns:field>
<Producer>
<ns:SomeQualifier/>
</Producer>
</ns:field>
</ns:Bean>
I have changed this to:
<ns:Bean>
<ns:field>
<Producer/>
<ns:SomeQualifier/>
</ns:field>
</ns:Bean>
Setting initial field values (implemented):
You can now do:
<ns:Bean>
<ns:field>
<Producer/>
<value>10</value>
</ns:field>
<ns:field2>5</ns:field2>
<ns:mapField>
<entry><key>a</key><value>b</value></entry>
<e><k>c</k><v>d</v></e>
</ns:mapField/>
</ns:Bean>
The value key and entry tags can be shorted to just <v><k> and <e> tags, not sure if this is a good idea or not. I would also like to add the ability to set field values using EL.
Vetoing beans using XML (implemented)
Syntax is:
<veto>
<ns:Bean1/>
<ns:Bean2/>
</veto>
Replacing and extending Beans (not implemented)
I would like to add <override> and <extends> tags that can be added as a direct child of a Bean element. The override tag will have the same effect as the veto tag above, i.e. preventing the default bean from being installed. The <extends> tag specifies that the annotation and configuration is added to the existing Bean definition instead of installing a new bean.
Change of syntax for constructor and method parameters (not implemented)
Currently method parameters are specified as direct children of the method like so:
<ns:Bean>
<ns:method>
<Producer/>
<ns:ParamType1><ns:SomeAnntation/></ns:ParamType1>
<ns:SomeOtherAnnotation/>
<ns:ParamType2/>
</ns:method>
</ns:Bean>
I think this is a bit confusing, as parameters and annotations can be interspeced at random and it is not immeditatly obvious which is which. I think it should be changed to:
<ns:Bean>
<ns:method>
<Producer/>
<ns:SomeOtherAnnotation/>
<parameters>
<ns:ParamType1><ns:SomeAnntation/></ns:ParamType1>
<ns:ParamType2/>
</parameters/>
</ns:method>
</ns:Bean>
Something similar should probably be done for the constructor parameters as well.
Factories for primitive types (not implemented)
<factory>
<String/>
<ns:SomeQualifier/>
<value>hello world</value>
</factory>
This would allow you to the inject a string with the qualifier @SomeQualifier.
Thoughts?
Stuart
16 years
Seam 2 and JSF 2 problem
by Norman Richards
I've been trying to track down a problem affecting several of the Seam 2 examples running on JBoss 6. It appears that JSF restoreView is now sometimes calling EL in places it didn't in earlier JSF versions. If that EL involves a conversation-scoped component, the application will fail since the conversation state is not active until after restoreView.
Ex:
/myView.xhtml contains an <h:dataTable value="#{searchResults}" ... etc/>
If the component that provides searchResults does @In for a conversation-scoped component, like ManagedPersistenceContext, the application will now fail.
Of course, the view works fine for GET requests, since there is no view being restored. Is this expected behavior for JSF 2, or is it perhaps a bug in the restore view implementation? I'm not familiar enough with the changes in JSF2 yet to know what to expect. Here's a stack trace to give some context. The key problems are around UIViewRoot.processRestoreState and UIData.visitTree.
Exception during request processing:
Caused by javax.servlet.ServletException with message: "@In attribute requires non-null value: searchService.entityManager"
javax.faces.webapp.FacesServlet.service(FacesServlet.java:323)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:60)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:40)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
org.jboss.seam.web.HotDeployFilter.doFilter(HotDeployFilter.java:53)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:183)
org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:95)
org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
java.lang.Thread.run(Thread.java:637)
Caused by org.jboss.seam.RequiredException with message: "@In attribute requires non-null value: searchService.entityManager"
org.jboss.seam.Component.getValueToInject(Component.java:2338)
org.jboss.seam.Component.injectAttributes(Component.java:1736)
org.jboss.seam.Component.inject(Component.java:1554)
org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:61)
org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:44)
org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68)
org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:107)
org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:185)
org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:103)
actions.SearchService_$$_javassist_seam_4.getSearchResults(SearchService_$$_javassist_seam_4.java)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:597)
org.jboss.seam.util.Reflections.invoke(Reflections.java:22)
org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:144)
org.jboss.seam.Component.callComponentMethod(Component.java:2249)
org.jboss.seam.Component.getInstanceFromFactory(Component.java:2080)
org.jboss.seam.Component.getInstance(Component.java:2011)
org.jboss.seam.Component.getInstance(Component.java:1983)
org.jboss.seam.Component.getInstance(Component.java:1977)
org.jboss.seam.Namespace.getComponentInstance(Namespace.java:55)
org.jboss.seam.Namespace.getComponentInstance(Namespace.java:50)
org.jboss.seam.el.SeamELResolver.resolveBase(SeamELResolver.java:148)
org.jboss.seam.el.SeamELResolver.getValue(SeamELResolver.java:51)
javax.el.CompositeELResolver.getValue(CompositeELResolver.java:54)
com.sun.faces.el.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:72)
org.jboss.el.parser.AstIdentifier.getValue(AstIdentifier.java:44)
org.jboss.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:186)
com.sun.facelets.el.TagValueExpression.getValue(TagValueExpression.java:71)
javax.faces.component.ComponentStateHelper.eval(ComponentStateHelper.java:190)
javax.faces.component.ComponentStateHelper.eval(ComponentStateHelper.java:178)
javax.faces.component.UIData.getValue(UIData.java:554)
javax.faces.component.UIData.getDataModel(UIData.java:1243)
javax.faces.component.UIData.setRowIndex(UIData.java:447)
javax.faces.component.UIData.visitTree(UIData.java:1179)
javax.faces.component.UIComponent.visitTree(UIComponent.java:1454)
javax.faces.component.UIViewRoot.processRestoreState(UIViewRoot.java:868)
com.sun.faces.application.StateManagerImpl.restoreView(StateManagerImpl.java:197)
org.jboss.seam.jsf.SeamStateManager.restoreView(SeamStateManager.java:76)
com.sun.faces.application.view.ViewHandlingStrategy.restoreView(ViewHandlingStrategy.java:131)
com.sun.faces.application.view.MultiViewHandler.restoreView(MultiViewHandler.java:143)
org.jboss.seam.jsf.SeamViewHandler.restoreView(SeamViewHandler.java:93)
com.sun.facelets.FaceletViewHandler.restoreView(FaceletViewHandler.java:316)
com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:199)
com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:110)
com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:310)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:60)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:40)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
org.jboss.seam.web.HotDeployFilter.doFilter(HotDeployFilter.java:53)
org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:183)
org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:95)
org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
java.lang.Thread.run(Thread.java:637)
16 years
What are the plans for seam 2.x?
by Denis Forveille
It seems that everybody get very excited about the development of Seam
v3 and that's cool.
But what about the development of Seam v2?
As discussed in the weld forum, us, users of seam v2/EJB 3.0 but poor
non glassfish v3 (or JBoss v6) users will have to wait for months
before we'll be able to use weld and seam v3 in production.
The question is what are the plans to maintain seam v2.2 until 1) seam
3 is GA and 2) WebSphere/Oracle/WebLogic/<name your production AS
here> offer a JEE6 compliant version of their AS?
All our development is based now on Seam v2 (and I hope many other
users in the world..) and we are very happy with it but I think a
clear statement should be made on the strategy for Seam v2.x in the
meantime for the current Seam users. Or maybe it is somewhere and i
missed it?
Personally I will continue to commit bug fixes when I see the fit for
this in Seam v2.x but what about the rest of you guys? At some point
I'll for sure try to participate to the Seam v3/Seam v2 integration
module when the time will come to migrate our apps (And WebSphere will
provide an implementation of CDI).
Is there a planned released date of Seam v2.2.1? (There are currently
1000+ JIRA entries for Seam v2, 100+ assigned to Seam v2.2.1)
Will we have a Seam v2.2.2 (or maybe v2.3) in the future?
Also for seam v2.0.3 which is in CR since months, should it be
possible to either release this version or cancel it? thanks
16 years
Re: [seam-dev] What are the plans for seam 2.x?
by Cody Lerum
If possible I would like to see the following make it into the next release
https://jira.jboss.org/jira/browse/JBSEAM-4517
https://jira.jboss.org/jira/browse/JBSEAM-3906
https://jira.jboss.org/jira/browse/JBSEAM-4441
https://jira.jboss.org/jira/browse/JBSEAM-4442
All contain patches and should be low risk.
Thanks!
-C
> From: seam-dev-bounces(a)lists.jboss.org [mailto:seam-dev-bounces@lists.jboss.org] On Behalf Of Norman Richards
> Sent: Wednesday, December 23, 2009 5:44 PM
> To: Dan Allen
> Cc: seam-dev(a)lists.jboss.org
> Subject: Re: [seam-dev] What are the plans for seam 2.x?
>
>
>
>
>
> On Dec 23, 2009, at 4:31 PM, Dan Allen wrote:
>
> Is there a planned released date of Seam v2.2.1? (There are currently
> 1000+ JIRA entries for Seam v2, 100+ assigned to Seam v2.2.1)
> Will we have a Seam v2.2.2 (or maybe v2.3) in the future?
>
> We did discuss this in the Seam meeting last week. We are very likely going to be getting a release out in early 2010 (I don't know the estimated date) for reasons you cited and because we'll need changes anyway for the Seam 3 - Seam 2 bridging effort.
>
>
>
> We're hoping to get 2.2.1.CR1 out in January. That's a rough estimate based on how long we anticipate the critical fixes taking. It could be sooner or later, but that's our hope. I'm going to do my best to see that issues in JIRA with verified fixes are included in the release. If there are issues that meet this criteria that interest anyone, they should ping me to me make sure that I don't overlook them. The important thing is that this is primarily a maintenance release and fixes that require large changes are likely going to be too risky for the release.
>
>
>
>
16 years
