geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jay D. McHugh" <...@jnwd.net>
Subject Re: Geronimo 2.1 and Seam
Date Mon, 10 Mar 2008 05:21:24 GMT
Hey all,

Gavin already responded to this.

He has said that the @Remove/@Destroy should not be considered a 
Lifecycle callback.  But that is what is causing the problem.

OpenEJB is throwing the exception because it is treating the @Remove as 
a callback - So, the getParameters() call is throwing the exception.

Where does the operation get set as being a callback?

Or, is the @Remove/@Destroy being correctly flagged?

I would guess that Gavin is right (But I am completely out of my depth 
to anything other than guess).

Jay

Burt Prior wrote:
> Hi All,
> 
> I've submitted the following Seam Bug: 
> http://jira.jboss.com/jira/browse/JBSEAM-2713 Seam Bug Report 
> 
> I hope I captured all of your excellent analysis and suggestions.  Please
> check it out when you get a chance, and feel free add any comments.
> 
> I'm hoping for a quick resolution after Gavin and his team has look at this.
> 
> Thanks,
> .Burt
> 
> 
> 
> Burt Prior wrote:
>> Hi Jay, (and David^2)
>>
>> Thanks for checking that.  I didn't have time to experiment with it on
>> Friday.  Darn. Ok, well.
>>
>> I just now checked my Seam users group posting on this.  It looks like
>> Gavin King replied.
>>
>> Please check it out, and don't hesitate to respond as well.
>>
>> http://www.seamframework.org/Community/Seam2JEE5CompliantWithTheTCKRequirements
>> Geronimo and Seam and TCK 
>>
>> Gavin mentioned to fill out a bug report.  Any suggestions?
>>
>> Thanks everyone.  This is really excellent.  I wonder if we could get some
>> kinda patch for Seam on Geronimo?
>> .Burt
>>
>>
>>
>>
>>
>> Jay D. McHugh-3 wrote:
>>> Hey Burt,
>>>
>>> I just tried removing the @Destroy annotations in the booking example 
>>> but the errors still pop up.
>>>
>>> Jay
>>>
>>> Burt Prior wrote:
>>>> Hi David,
>>>>
>>>> I just posted on SeamFramework.org:
>>>>
>>>> http://www.seamframework.org/Community/Seam2JEE5CompliantWithTheTCKRequirements
>>>> Seam Posting 
>>>>
>>>> I'm hoping to get some way to resolve this issue soon.
>>>>
>>>> Perhaps its as you mentioned:  Can't I just safely remove @Destroy?
>>>>
>>>> Thanks,
>>>> .Burt
>>>>
>>>>
>>>>
>>>>
>>>> djencks wrote:
>>>>> On Mar 7, 2008, at 2:51 PM, Burt Prior wrote:
>>>>>
>>>>>> Hi David and David,
>>>>>>
>>>>>> First, thank you both for helping us.  Our team has been hanging
on  
>>>>>> your
>>>>>> every post!
>>>>>>
>>>>>>> Do you have any evidence that seam runs with a bean with a @Destroy
>>>>>>> annotated method on any certified platform?
>>>>>> I sure don't, other than latest Seam doc/articles i've went thru
here:
>>>>>> http://seamframework.org/Documentation/GettingStarted Getting  
>>>>>> Started with
>>>>>> Seam
>>>>>>
>>>>>> Also, this booking example is the 'jee5' booking example; there is
 
>>>>>> a 'non
>>>>>> jee5' booking example as well in every Seam download.  I think the
 
>>>>>> 'non
>>>>>> jee5' uses plain JavaBean and Hibernate instead of EJB3 and JPA.
>>>>>>
>>>>>> The only other JEE5 certified platform I know of that works with
 
>>>>>> Seam is
>>>>>> GlassFish.  Not from personal exerience but from articles from Sun
 
>>>>>> and Seam.
>>>>>> http://weblogs.java.net/blog/caroljmcdonald/archive/2007/07/ 
>>>>>> sample_applicat_1.html
>>>>>> GlassFish and Seam
>>>>>>
>>>>>> I was just wondering. Anyone running Seam on a JEE5 compliant  
>>>>>> server such
>>>>>> Geronimo or GlassFish must get the same error?
>>>>> Well, if they have an ejb with a @Destroy method we think they will 

>>>>> get this error.  The glassfish example for v2 does have one @Destroy
 
>>>>> method in CatalogBean but my experience trying to extract information
 
>>>>> from Glassfish has not been a happy one so I haven't tried anything 

>>>>> on it.
>>>>>
>>>>>>> Also, it doesn't make much sense.
>>>>>> Yes, i agree.  All the errors we solved to get to this point 'made
 
>>>>>> sense'.
>>>>>> But when I saw this error, and read David's response, i thought we
 
>>>>>> were in
>>>>>> trouble;  If I'm hitting up against the spec, and I can't change
my  
>>>>>> code,
>>>>>> where does that leave my architecture?  (Geronimo, EJB3, Seam,  
>>>>>> Oracle, JPA,
>>>>>> JSF).
>>>>>>
>>>>>>> I would think the jboss/seam developers would be the ones to
start  
>>>>>>> this
>>>>>>> although we  might challenge it also.
>>>>>> Yes, I will post on the appropriate Seam list today.  I guess the
 
>>>>>> question
>>>>>> is to focus on @Destroy?  How would you phrase it?
>>>>>>
>>>>>> What also doesn't make sense is the Seam doc for @Destroy.  Why do
 
>>>>>> we see
>>>>>> any issue at all?
>>>>>> http://docs.jboss.com/seam/2.1.0.A1/reference/en/html/ 
>>>>>> annotations.html#d0e19563
>>>>>> Seam @Destroy Annotation
>>>>>>
>>>>>>
>>>>>>> The challenge process typically takes a while.
>>>>>> Yes.  Not really an option for us.  We are trying get our Geronimo
 
>>>>>> app out
>>>>>> now.
>>>>>>
>>>>>>> Other than filling up your logs what problems is this causing?
>>>>>> There appears to be no other errors or problems.  I've been  
>>>>>> exercising the
>>>>>> app, watching the console log in real time in the eclipse console,
 
>>>>>> then
>>>>>> checking the db.  It appears to work fine.  It throws the  
>>>>>> exceptions, then
>>>>>> recovers.  It's always the same error: 'Callback methods cannot access
>>>>>> parameters'.
>>>>>>
>>>>>>> Seeing the entire stack trace from your bean's @Destroy method
to the
>>>>>>> original exception might possibly shed more light on the subject.
>>>>> Does the destroy method on your beans actually do anything?  If, like
 
>>>>> the samples, it does nothing, the simplest solution is to leave it  
>>>>> out.  If if does do something, does it get called?  My belief from  
>>>>> the stack trace is that it does not due to the  exception.
>>>>>
>>>>> As for wording... that's tricky.  I guess I'd say that running the  
>>>>> app on the geronimo/openejb javaee5 certified container results in  
>>>>> the stack trace and that allowing the InvocationContext to supply the
 
>>>>> parameters during a lifecycle call results in tck failures.  I'd ask
 
>>>>> if they can run the sample with the @Destroy method getting called on
 
>>>>> a certified container without getting an exception and perhaps  
>>>>> mention that we aren't aware of any support in the spec itself for  
>>>>> this requirement.
>>>>>
>>>>> I'd include this part of the stack trace:
>>>>>
>>>>> 11:25:05,179 ERROR [OpenEJB] The bean instance business method  
>>>>> encountered a
>>>>> system exception: Callback methods cannot access parameters
>>>>> java.lang.IllegalStateException: Callback methods cannot access  
>>>>> parameters
>>>>> 	at
>>>>> org.apache.openejb.core.interceptor.ReflectionInvocationContext.getParam

>>>>> eters(ReflectionInvocationContext.java:71)
>>>>> 	at
>>>>> org.jboss.seam.intercept.EJBInvocationContext.getParameters 
>>>>> (EJBInvocationContext.java:34)
>>>>> 	at
>>>>> org.jboss.seam.intercept.SeamInvocationContext.getParameters 
>>>>> (SeamInvocationContext.java:49)
>>>>> 	at
>>>>> org.jboss.seam.core.MethodContextInterceptor.aroundInvoke 
>>>>> (MethodContextInterceptor.java:33)
>>>>> 	at
>>>>> org.jboss.seam.intercept.SeamInvocationContext.proceed 
>>>>> (SeamInvocationContext.java:68)
>>>>> 	at
>>>>> org.jboss.seam.persistence.EntityManagerProxyInterceptor.aroundInvoke

>>>>> (EntityManagerProxyInterceptor.java:26)
>>>>> 	at
>>>>> org.jboss.seam.intercept.SeamInvocationContext.proceed 
>>>>> (SeamInvocationContext.java:68)
>>>>> 	at
>>>>> org.jboss.seam.persistence.HibernateSessionProxyInterceptor.aroundInvoke

>>>>> (HibernateSessionProxyInterceptor.java:27)
>>>>> 	at
>>>>> org.jboss.seam.intercept.SeamInvocationContext.proceed 
>>>>> (SeamInvocationContext.java:68)
>>>>> 	at
>>>>> org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:

>>>>> 107)
>>>>> 	at
>>>>> org.jboss.seam.intercept.SessionBeanInterceptor.aroundInvoke 
>>>>> (SessionBeanInterceptor.java:50)
>>>>> 	at sun.reflect.GeneratedMethodAccessor144.invoke(Unknown Source)
>>>>> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>>>>> 	at java.lang.reflect.Method.invoke(Unknown Source)
>>>>> 	at
>>>>> org.apache.openejb.core.interceptor.ReflectionInvocationContext 
>>>>> $Invocation.invoke(ReflectionInvocationContext.java:146)
>>>>> 	at
>>>>> org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(

>>>>> ReflectionInvocationContext.java:129)
>>>>> 	at
>>>>> org.apache.openejb.core.interceptor.InterceptorStack.invoke 
>>>>> (InterceptorStack.java:67)
>>>>> 	at
>>>>> org.apache.openejb.core.stateful.StatefulContainer._invoke 
>>>>> (StatefulContainer.java:428)
>>>>> 	at
>>>>> org.apache.openejb.core.stateful.StatefulContainer.removeEJBObject 
>>>>> (StatefulContainer.java:332)
>>>>> 	at
>>>>> org.apache.openejb.core.stateful.StatefulContainer.invoke 
>>>>> (StatefulContainer.java:244)
>>>>> 	at
>>>>> org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod 
>>>>> (EjbObjectProxyHandler.java:217)
>>>>> 	at
>>>>> org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke 
>>>>> (EjbObjectProxyHandler.java:77)
>>>>> 	at
>>>>> org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke 
>>>>> (BaseEjbProxyHandler.java:321)
>>>>> 	at
>>>>> org.apache.openejb.util.proxy.Jdk13InvocationHandler.invoke 
>>>>> (Jdk13InvocationHandler.java:49)
>>>>> 	at $Proxy76.destroy(Unknown Source)
>>>>> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>> 	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>>>>> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>>>>> 	at java.lang.reflect.Method.invoke(Unknown Source)
>>>>> 	at org.jboss.seam.util.Reflections.invoke(Reflections.java:21)
>>>>> 	at
>>>>> org.jboss.seam.intercept.RootInvocationContext.proceed 
>>>>> (RootInvocationContext.java:31)
>>>>> 	at
>>>>> org.jboss.seam.intercept.ClientSideInterceptor$1.proceed 
>>>>> (ClientSideInterceptor.java:76)
>>>>> 	at
>>>>> org.jboss.seam.intercept.SeamInvocationContext.proceed 
>>>>> (SeamInvocationContext.java:56)
>>>>> 	at
>>>>> org.jboss.seam.ejb.RemoveInterceptor.aroundInvoke 
>>>>> (RemoveInterceptor.java:41)
>>>>> 	at
>>>>> org.jboss.seam.intercept.SeamInvocationContext.proceed 
>>>>> (SeamInvocationContext.java:68)
>>>>> 	at
>>>>> org.jboss.seam.core.SynchronizationInterceptor.aroundInvoke 
>>>>> (SynchronizationInterceptor.java:32)
>>>>> 	at
>>>>> org.jboss.seam.intercept.SeamInvocationContext.proceed 
>>>>> (SeamInvocationContext.java:68)
>>>>> 	at
>>>>> org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:

>>>>> 107)
>>>>> 	at
>>>>> org.jboss.seam.intercept.ClientSideInterceptor.invoke 
>>>>> (ClientSideInterceptor.java:54)
>>>>> 	at
>>>>> org.javassist.tmp.java.lang.Object_$$_javassist_4.destroy(Object_$ 
>>>>> $_javassist_4.java)
>>>>> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>> 	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>>>>> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>>>>> 	at java.lang.reflect.Method.invoke(Unknown Source)
>>>>> 	at org.jboss.seam.util.Reflections.invoke(Reflections.java:21)
>>>>> 	at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:125)
>>>>> 	at org.jboss.seam.Component.callComponentMethod(Component.java:2084)
>>>>> 	at org.jboss.seam.Component.callDestroyMethod(Component.java:2015)
>>>>> 	at org.jboss.seam.Component.destroy(Component.java:1331)
>>>>> 	at org.jboss.seam.contexts.Contexts.destroy(Contexts.java:251)
>>>>> 	at org.jboss.seam.contexts.Lifecycle.endSession(Lifecycle.java:249)
>>>>> 	at
>>>>> org.jboss.seam.contexts.ServletLifecycle.endSession 
>>>>> (ServletLifecycle.java:129)
>>>>> 	at
>>>>> org.jboss.seam.servlet.SeamListener.sessionDestroyed 
>>>>> (SeamListener.java:49)
>>>>> 	at
>>>>> org.mortbay.jetty.servlet.AbstractSessionManager.removeSession 
>>>>> (AbstractSessionManager.java:665)
>>>>> 	at
>>>>> org.mortbay.jetty.servlet.AbstractSessionManager$Session.invalidate 
>>>>> (AbstractSessionManager.java:938)
>>>>> 	at
>>>>> org.mortbay.jetty.servlet.HashSessionManager$Session.invalidate 
>>>>> (HashSessionManager.java:493)
>>>>> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>>> 	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
>>>>> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
>>>>> 	at java.lang.reflect.Method.invoke(Unknown Source)
>>>>> 	at
>>>>> org.jboss.seam.contexts.FacesLifecycle.invalidateSession 
>>>>> (FacesLifecycle.java:141)
>>>>> 	at
>>>>> org.jboss.seam.contexts.FacesLifecycle.endRequest(FacesLifecycle.java:

>>>>> 118)
>>>>> 	at
>>>>> org.jboss.seam.jsf.SeamPhaseListener.afterRenderResponse 
>>>>> (SeamPhaseListener.java:515)
>>>>> 	at
>>>>> org.jboss.seam.jsf.SeamPhaseListener.afterServletPhase 
>>>>> (SeamPhaseListener.java:247)
>>>>> 	at
>>>>> org.jboss.seam.jsf.SeamPhaseListener.afterPhase 
>>>>> (SeamPhaseListener.java:194)
>>>>> 	at
>>>>> org.apache.myfaces.lifecycle.PhaseListenerManager.informPhaseListenersAf

>>>>> ter(PhaseListenerManager.java:92)
>>>>> 	at
>>>>> org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:

>>>>> 142)
>>>>> 	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:152)
>>>>> 	at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:

>>>>> 487)
>>>>> 	at
>>>>> org.apache.geronimo.jetty6.InternalJettyServletHolder.handle 
>>>>> (InternalJettyServletHolder.java:65)
>>>>> 	at
>>>>> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter 
>>>>> (ServletHandler.java:1093)
>>>>> 	at
>>>>> org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter 
>>>>> (SeamFilter.java:83)
>>>>> 	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:

>>>>> 141)
>>>>> 	at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:281)
>>>>> 	at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56)
>>>>> 	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.debug.hot.HotDeployFilter.doFilter 
>>>>> (HotDeployFilter.java:68)
>>>>> 	at
>>>>> org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter 
>>>>> (SeamFilter.java:69)
>>>>> 	at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
>>>>> 	at
>>>>> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter 
>>>>> (ServletHandler.java:1084)
>>>>> 	at org.mortbay.jetty.servlet.ServletHandler.handle 
>>>>> (ServletHandler.java:360)
>>>>> 	at
>>>>> org.mortbay.jetty.security.SecurityHandler.handle 
>>>>> (SecurityHandler.java:216)
>>>>> 	at org.mortbay.jetty.servlet.SessionHandler.handle 
>>>>> (SessionHandler.java:181)
>>>>> 	at org.mortbay.jetty.handler.ContextHandler.handle 
>>>>> (ContextHandler.java:726)
>>>>> 	at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:

>>>>> 405)
>>>>> 	at
>>>>> org.apache.geronimo.jetty6.handler.TwistyWebAppContext.access$101 
>>>>> (TwistyWebAppContext.java:40)
>>>>> 	at
>>>>> org.apache.geronimo.jetty6.handler.TwistyWebAppContext 
>>>>> $TwistyHandler.handle(TwistyWebAppContext.java:65)
>>>>> 	at
>>>>> org.apache.geronimo.jetty6.handler.ThreadClassloaderHandler.handle 
>>>>> (ThreadClassloaderHandler.java:46)
>>>>> 	at
>>>>> org.apache.geronimo.jetty6.handler.InstanceContextHandler.handle 
>>>>> (InstanceContextHandler.java:58)
>>>>> 	at
>>>>> org.apache.geronimo.jetty6.handler.UserTransactionHandler.handle 
>>>>> (UserTransactionHandler.java:48)
>>>>> 	at
>>>>> org.apache.geronimo.jetty6.handler.ComponentContextHandler.handle 
>>>>> (ComponentContextHandler.java:47)
>>>>> 	at
>>>>> org.apache.geronimo.jetty6.handler.TwistyWebAppContext.handle 
>>>>> (TwistyWebAppContext.java:59)
>>>>> 	at
>>>>> org.mortbay.jetty.handler.ContextHandlerCollection.handle 
>>>>> (ContextHandlerCollection.java:206)
>>>>> 	at
>>>>> org.mortbay.jetty.handler.HandlerCollection.handle 
>>>>> (HandlerCollection.java:114)
>>>>> 	at org.mortbay.jetty.handler.HandlerWrapper.handle 
>>>>> (HandlerWrapper.java:139)
>>>>> 	at org.mortbay.jetty.Server.handle(Server.java:324)
>>>>> 	at org.mortbay.jetty.HttpConnection.handleRequest 
>>>>> (HttpConnection.java:505)
>>>>> 	at
>>>>> org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete 
>>>>> (HttpConnection.java:828)
>>>>> 	at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:514)
>>>>> 	at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
>>>>> 	at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
>>>>> 	at
>>>>> org.mortbay.io.nio.SelectChannelEndPoint.run 
>>>>> (SelectChannelEndPoint.java:395)
>>>>> 	at org.apache.geronimo.pool.ThreadPool$1.run(ThreadPool.java:214)
>>>>> 	at
>>>>> org.apache.geronimo.pool.ThreadPool$ContextClassLoaderRunnable.run 
>>>>> (ThreadPool.java:344)
>>>>> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown  
>>>>> Source)
>>>>> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
>>>>> 	at java.lang.Thread.run(Unknown Source)
>>>>>
>>>>>
>>>>> <snip>
>>>>>
>>>>> Hope this helps
>>>>> thanks
>>>>> david jencks
>>>>>
>>>>>
>>>>>
>>>
>>
> 


Mime
View raw message