Here is some of the advantages by using Seam-managed JavaBeans. I suppose someone out there is better suited than me to explain the advantages of EJB.

• You are not forced to write interfaces for every class.
• You can work outside an EJB-container, making it much more convenient when using servlet containers like Jetty.
• There is less boilerplate configuration.
• Hot-deployment of components by the special Seam Classloader is possible.
• For regular non-clustered use, it's a bit faster.

Using Seam EJB3 components you benefit very useful features of EJB3.

In the reference manual (§4.2.4) you can read this :

Javabeans may be used just like a stateless or stateful session bean. However, they do not provide the functionality of a session bean (declarative transaction demarcation, declarative security, efficient clustered state replication, EJB 3.0 persistence, timeout methods, etc).

Olivier Thierry wrote on Jan 20, 2009 15:16:
Using Seam EJB3 components you benefit very useful features of EJB3. In the reference manual (§4.2.4) you can read this : Javabeans may be used just like a stateless or stateful session bean. However, they do not provide the functionality of a session bean (declarative transaction demarcation, declarative security, efficient clustered state replication, EJB 3.0 persistence, timeout methods, etc).

This is AFAIK true:

1. efficient clustered state replication: Of course the question here could be: How much efficiency do you really need? is plan Tomcat clustering good enough for you? if it is, the you do not need EJBs.

This are, AFAIK false:

1. declarative transaction demarcation: AFAIK the annotation org.jboss.seam.annotations.Transactional works for POJOs
2. declarative security: Mmmm, I believe that org.jboss.seam.annotations.security.Restrict works for POJOs... Am I wrong?
3. EJB 3.0 persistence: This is also available if you use POJOs, it is called JPA ;-)

And this, I just do not know:

1. timeout methods: Timeouts... for what exactly?

Click HELP for text formatting instructions. Then edit this text and check the preview.

I use almost exclusively EJB3 SLSB and SFSB. It works quite well.

However, the only real complaint I have is not being able to hot deploy components.

Vote for EJBTHREE-1096

It has a very large number of votes, but is consistently ignored and has no comments on how, if, or when this might be a reality.

Redeployment of my ear, which is getting larger and larger, is sucking up ridiculous amounts of time.

And, I do not want to switch to POJOs because I am unsure of the subtle differences that might break my application.

That is the only reason I can see not to use EJB3, but it is a big one.

Any suggestions on how to improve the development process with Seam and EJB3 would be most welcome.

Well, based on you post, I see an implicit reason not to use EJBs: You couldn't name a single good reason to use them.

And you did provide me with a really good reason not to use EJBs (EJBTHREE-1096).

Long life to POJOs! Death to EJBs! ;-)

Well I adopted this child when Seam first came out and it was plugged as the magic glue to make JSF and EJB3 a dream come true.

For my case I probably do not need them. I do not use clustering, but I do plan on using MDB soon.

I have been raising this child for a long time and I have a few hundred SLSB nd SFSB beans.

I don't feel like it would be trivial to switch.

Has anyone made a large scale switch from EJB3 to Seam POJOs in a production application?

Has anyone made a large scale switch from EJB3 to Seam POJOs in a production application?

We did, and it was very easy, and eliminated a number of problems we were having, particularly with respect to clustering/passivation/threading/classloading It also sped up startup of jboss in development and of embeddedJboss in testing quite a bit. And we're just getting ready to eliminate our dependency on embeddedJboss at test time altogether, by moving away from a JNDI-based entityManagerFactory and JTA during testing, which were the last EE dependencies of ours.

We had a hundred or so SLSBs, and a dozen or so SFSBs.

It was probably easier for us because we adopted EJB when we adopted seam, and so we did all our injections with seam annotations, not EJB3 annotations. It was therefore simply a matter of exchanging @Stateful and @Stateless in favor of @Scope annotations, adding @Transactional annotations, and getting rid of a zillion interfaces (something I dearly hate about EJBs.) I did it with a perl script :)

JPA is great, as is JTA. But the rest of EJB3 is problematic, IMHO, and should only be leveraged if you really need it.

I have been attempting to switch from EJB3 to POJO because it is totally killing my productivity as my project grows.

Also EJBTHREE-1096 seems totally dead even though it has a very large number of votes and interest.

I removed the @Stateless and added @Scope annotations, adding @Transactional, but my problem is that all my SLSB DAOs(over 100) use

    @PersistenceContext 
    public EntityManager entityManager;

This behaves differently due to the fact that it propagated across the transaction rather than the conversation if I switch to

    @In 
    public EntityManager entityManager;

I get an error when trying to use @PersistenceContext without @Stateless or @Stateful and my application behaves differently using the SMPC.

How can I get the EntityManager to behave like using @PersistenceContext in a Seam component that is not a SLSB or SFSB?

Using an event scoped entity manager would stop the entityManager being propagated with the conversation. The behavior is not exactly the same, but it is close. Notable differences are that the entityManager would span 2 transactions (as seam creates 2 transactions for each page view) and you no longer have access to the REQUIRES_NEW transaction attribute. There are probably other differences as well, but I can't think what they are off the top of my head.

Jason, have you looked at JavaRebel? we have an ejb3 seam app and find JavaRebel helps a lot. It doesn't pick up new functions or variables in a class, but often with debugging etc the changes are going on inside a function and JavaRebel gives us instant hot deployment of entity and session beans for this scenario.

Really.

How is this different from JVM HotSwap?

I think this is a very wild guess, but... have you tried EasyBeans and Tomcat? it seems that EasyBeans comes as an OSGi bundle, and (maybe, and this is a really big maybe) it could natively support hot deployment (I know for sure that OSGi can do it, the question here is... EasyBeans makes it possible to do it with EBJs? )

At least the seem to be trying to do it. Of course, it could be ready when it is too late for your project

Thanks for the tip. I wonder how difficult it would be for JBAS to support this.

I looked at EasyBeans. I would rather not switch EJB3 implementations.

I guess it is not that simple to get a SMPC that behaves like a CMPC and I am stuck with this for now.

Any other suggestions are welcome.

Hi..

Hi buddy...sorry because my reply is not related with the question which is being discussed right now..but will u please devote some time of yours to me..because..i am an amature to seam and not getting the essence of .page.xml files in Seam 2.1.0... I will be thankfull if you can help me out..

Thanks and regards Prasad.

Hmmm! You know it is it not related and yet you post it in this thread. :)

Please create a new topic and please refrain using unrelated topics.

Jason Long wrote on Feb 13, 2009 19:57:
Really. How is this different from JVM HotSwap?

The differences

Willy S wrote on Feb 13, 2009 18:49:
Jason, have you looked at JavaRebel? we have an ejb3 seam app and find JavaRebel helps a lot. It doesn't pick up new functions or variables in a class, but often with debugging etc the changes are going on inside a function and JavaRebel gives us instant hot deployment of entity and session beans for this scenario.

JavaRebel does pick up functions or variables in a class. Sun JVM HotSwap does not.

Francisco Peredo wrote on Feb 15, 2009 03:02:
JavaRebel does pick up functions or variables in a class. Sun JVM HotSwap does not.

Francisco, have you tried JavaRebel with EJBs? or did you try it only with POJOs?

Mmm, only on POJOs, and only for a few days... (only trial period, super low budget here).

So I am no expert, but it did pick up functions or variables in classes.... of course it could be that it failed with EJBs (another reason no to use them ;). But it seems like they believe it works.

We use JavaRebel with EJB. it doesn't pick up new functions on entity or session beans, but as stated earlier we still find it helpful as it handles code changes inside functions. Just hit explode and a few seconds later the change is live.

Have you reported this problem to the JavaRebel guys ( support@zeroturnaround.com )? Maybe you are doing something wrong and because of that missing some nice features...

According to this article, JavaRebel 2.0 ( released March 25th, 2009 ) has support for WAR and EAR hot-deployments.

The reson why it cannot add business methods to ejb's is because the ejb's are accessed through a proxy generated by the ejb container. The proxy has to be updated as well as the base class, so someone whould have to write a javarebel plugin that updates the proxy.

Francisco Peredo wrote on Apr 07, 2009 23:08:
According to this article, JavaRebel 2.0 ( released March 25th, 2009 ) has support for WAR and EAR hot-deployments.

I just watched the JR demo (petclinic spring, funny how Seam is not even listed :) and read the infoq article, etc.

So does JR support EJB (session bean, message driven bean and entity class) hot deploy or not???

Stuart Douglas wrote on Apr 08, 2009 00:22:
The reson why it cannot add business methods to ejb's is because the ejb's are accessed through a proxy generated by the ejb container. The proxy has to be updated as well as the base class, so someone whould have to write a javarebel plugin that updates the proxy.

so that's a deal-breaker for me, esp. if it's not open-source (free)...

I want 100% hot deployment for all EJB components and entity classes!

why doesn't zeroturnaround write that plugin that updates the proxy? if that a very difficult task? there's a pretty big market out there for EJB hot-deployment...

so is it worthwhile to buy this JR plugin for Seam development or not if you're using lots of SFSBs, for example and need hot-deployment (2.0 features WAR/EAR hot deploy)?

found a mention to Seam here: My Link

Throwaway class loaders. Several frameworks (including Tapestry 5, RIFE, Seam, Grails and so on) will instantly reload the changes to the code of the managed components (e.g. beans, pages, controllers, etc). This is possible by wrapping a throwaway class loader around the managed component and recreating its instance after every change. Unfortunately this solution works only for managed components and the rest of the code cannot be reloaded. It can also cause weird ClassCastExceptions and other similar problems due to class loader migration problems. JavaRebel works for any class in your system, preserves all the current object instances and does not exhibit any class loader-related problems.

Is that ClassCastExceptions true for Seam? Never really noticed that...

Also note that it states in the above quote this: JavaRebel works for any class in your system

SFSB is a class, no?

ok, hold on. check this out:

is this true?

Implementation changes are definitely supported. JavaRebel also supports changes to EJB interfaces in containers that use proxies (e.g. JBoss), though it doesn't always work perfectly.

My Link

well I posted a question regarding EJB hot deployment on the JR 2.0 tss thread here:

http://www.theserverside.com/news/thread.tss?m=c.reply&thread_id=54088#307193

perhaps the devs themselves will answer...

well I downloaded JR 2.0 and setup with JBDS/JBoss.

here are some quick testing results:

hot deploy works for the following scenario (this is a SFSB):

public void myAction() {
		log.info("begin myAction");		
	}

when I added the add'l log.info() below and exec'd 'ant explode', the hot deploy change picked up!

public void myAction() {
		log.info("begin myAction");
		log.info("new comment for JR 2.0");		
	}

when I added a param to the method as follows:

public void myAction(String value) {
		log.info("begin myAction");
		log.info("new comment for JR 2.0");		
	}

and in the local interface for this SFSB, i got an exception/stack trace (see below). Same exception when I added a business method (public method and new method in local interface).

So apparently Stuart is correct and there are some obvious limitations to this plugin (or I've configured incorrectly possibly).

16:41:52,052 ERROR [ExceptionFilter] handling uncaught exception
javax.servlet.ServletException: Servlet execution threw an exception
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:313)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at jcifs.http.NtlmHttpFilter.doFilter(NtlmHttpFilter.java:125)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
	at org.jboss.seam.debug.hot.HotDeployFilter.doFilter(HotDeployFilter.java:68)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:85)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:154)
	at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:260)
	at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:366)
	at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:493)
	at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:60)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
	at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
	at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:182)
	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433)
	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
	at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241)
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:580)
	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
	at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.AbstractMethodError: org.javassist.tmp.java.lang.Object_$$_javassist_6.__jr_selector__(I[Ljava/lang/Object;)Ljava/lang/Object;
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at com.zeroturnaround.javarebel.cA.invoke(JavaRebel:576)
	at java.lang.reflect.Method.invoke(Method.java)
	at org.jboss.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:329)
	at org.jboss.el.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:342)
	at org.jboss.el.parser.AstPropertySuffix.invoke(AstPropertySuffix.java:58)
	at org.jboss.el.parser.AstValue.invoke(AstValue.java:96)
	at org.jboss.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276)
	at com.sun.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:68)
	at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:88)
	at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:102)
	at javax.faces.component.UICommand.broadcast(UICommand.java:387)
	at org.ajax4jsf.component.AjaxViewRoot.processEvents(AjaxViewRoot.java:317)
	at org.ajax4jsf.component.AjaxViewRoot.broadcastEvents(AjaxViewRoot.java:292)
	at org.ajax4jsf.component.AjaxViewRoot.processPhase(AjaxViewRoot.java:249)
	at org.ajax4jsf.component.AjaxViewRoot.processApplication(AjaxViewRoot.java:462)
	at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:82)
	at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100)
	at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:265)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
	... 41 more

The problem is that Java Rebel has no way to know what code should go in the Proxy method, and every ejb implementation would need different code. The only way to implement EJB hot deploy is to get the container to re-generate the proxy. You also need to get seam to recognize that the ejb has changed and re-deploy it as a seam component as well (e.g. if you add or remove and observer method seam needs to know).

Maybe we need a JavaRebel plugin for Seam?

You would also need a java rebel plugin for jboss ejb3 (actually it would probably have to do both as you would have to make sure you deployed the ejb before you redeployed the seam component).

Hi guys!

I'm one of the JavaRebel developers from ZeroTurnaround. Arbi contacted us about the issue and I hope I can clear up some issues.

In the current state we do not support changes to the Local/Remote interfaces in the EJBs. This is mostly due to the EJB compilation step in most containers that is hard to make on-the-fly. JBoss actually generates proxies instead, so it should be quite possible to support it. However this does require a JBoss specific plugin that should take care of the extra methods, which are proxied by the select methods and some others.

The good news is that we always planned to get to this support and create a Proxy API that will allow you to handle dynamic proxies with JavaRebel better. This API is scheduled to be included in the next release. The bad news is that our team is quite small and we don't have time to become experts in every technology, so we always rely on community help to build our plugins. If you're interested in this, I'm sure we could make JBoss/Seam even more awesome together :)

Thanks!

Hello Arbi.

well I downloaded JR 2.0 and setup with JBDS/JBoss. here are some quick testing results: hot deploy works for the following scenario (this is a SFSB):

Would you mind sharing how you configured your seam app for java rebel? I am currently trying out java rebel but when I execute the explode target my whole app gets redeployed. I don't see how I can reduce time needed for deployment like this.

Any hint would be appreciated. Thanks in advance.

explode will only re-package and deploy your EAR and/or WAR if the EAR and/or WAR doesn't already exist in the exploded-archives directory in your project.

typically, explode will build (if required, .xhtml, .css, etc don't build) and copy the appropriate files to the server/xxx/deploy directory.

did your explode target behave like deploy prior to java rebel config?

you need to check your build.xml if so.

explode will only re-package and deploy your EAR and/or WAR if the EAR and/or WAR doesn't already exist in the exploded-archives directory in your project.

Thanks for the hint. My build.xml was actually fine, but I had clean executed always before explode in my eclipse build configuration...

Removing that seems to bring the desired effects. Thanks again.

I need to start a project and make this decision also.

My concern is that if I will not use EJB I will be stuck with one EAR with only WAR inside, as I will not be able to call my POJO's from a different EAR. I need to call my Facade beans exposed in one app from another EAR app, locally or remote, or from another WAR app.

I don't see how to do this with POJO's and without WebServices.

Clint, as you use EJB's in large projects and switched to POJO can I ask you how did you managed to resolve this problem?

Radu B wrote on May 11, 2009 18:28:
I need to start a project and make this decision also. My concern is that if I will not use EJB I will be stuck with one EAR with only WAR inside, as I will not be able to call my POJO's from a different EAR. I need to call my Facade beans exposed in one app from another EAR app, locally or remote, or from another WAR app. I don't see how to do this with POJO's and without WebServices. Clint, as you use EJB's in large projects and switched to POJO can I ask you how did you managed to resolve this problem?

One deployment archive to rule them all.

We started off attempting to maintain separate delpoyments for different sets of EJBs, multiple WARs, etc. It was a real pain. In the end we've moved to a single deployment. None of the app servers I have encountered can survive for very long in terms of memory if you're reloading new EARS/WARS, so you have to bring down the server anyway at some point, which means you have to figure out how to do that without messing up your users. If you know how to do that, you might as well bring them down for all deployments, because it gives you a clean slate. We've opted for multiple source maven modules that we eventually combine into a single deployment, and a carefully managed deployment strategy and buddy-clustering that allows us to roll deployments in a cluster without disturbing users.

In the case of truly needing cross-deployment invocation we sometimes use JMS, but mostly we use RESTful APIs. Much cleaner, works independent of app (or servlet) container, works without strange library dependencies...you know, it just, well, works :)

Thanks for reply!

Using multiple WAR or EAR was my idea on how to implement additional security restrictions based on virtualhost names and domains. The thing is that I will have a part of the application exposed to external users, which should be able to see only a sub-set of data from the database.

Each EAR can have his own Identity classes and login modules and by exposing only some Entity sub-classes to remote interfaces I can make sure my sensitive data will not be exposed.

I'm totally agree that maintaining library dependencies can become a nightmare...

Stuart give me a very nice suggestion in another post to implement security in an application like this by playing with virtual pages and page action, but it seems to me like a nice hack and not a best-practice.

Any idea on how to secure data for external access and use POJO instead of remote EJB interfaces will be greatly appreciated. Thanks again.

Radu B wrote on May 11, 2009 20:41:
Thanks for reply! Using multiple WAR or EAR was my idea on how to implement additional security restrictions based on virtualhost names and domains. The thing is that I will have a part of the application exposed to external users, which should be able to see only a sub-set of data from the database. Each EAR can have his own Identity classes and login modules and by exposing only some Entity sub-classes to remote interfaces I can make sure my sensitive data will not be exposed.

Once upon a time I tried doing exactly that, and There Be Dragons. It's much easier for a single app to have a single Identity with multiple access principals, and to use @Restrict or pages.xml to limit who sees what.

Stuart give me a very nice suggestion in another post to implement security in an application like this by playing with virtual pages and page action, but it seems to me like a nice hack and not a best-practice.

I'm not sure why page actions are being considered a hack. Well, any more than I find JSF as a whole to be rather hackish :P

Any idea on how to secure data for external access and use POJO instead of remote EJB interfaces will be greatly appreciated. Thanks again.

POJO Seam beans (and eventually POJO WebBeans, once Seam3 is ready) can be annotated with @Restrict, which will secure their use based on the current Identity.

I'm using @Restrict and security rules now (which I think are great). Also, page actions works very nice. Everything works ok AND was easy to develop and maintain.

To be honest, I was accepting a little hard the idea to leave everything related to security in the hand of seam @Restrict...

I'm glad to see that other people use this in production.

To be on topic, I think that WebBeans are clearly the way to go in the near future and migration from Seam components should much easier that from EJB. And developing with Seam components is like watching a football game comparing with EJB suite.

P.S. 'cos I'm a little bit paranoid about security, I've set the internal screens in a folder that requires https and configured JBoss to ask for the client certificate authentication...

There is a patch on the JIRA that should fix all the multi-war issues with seam attached to JBSEAM-3119, so hopefully multi war setups will be an option in the future.

This is scheduled for 2.2, however there are no guarantees that the patch will be accepted, as it is quite invasive.