JBossDeveloper

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!

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.

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...