4 Replies Latest reply on Jun 4, 2009 11:00 AM by jaikiran

    Variable argument list in session bean method causes NoSuchM

    ablevine1

      I am in the process of upgrading from jboss 4.0.5 to jboss 5.1.0 and am getting NoSuchMethodErrors when accessing my session beans that have methods containing variable argument lists (...). Is this a know issue for jboss? I see something similar about weblogic. For example I have this method in my interface:

      public interface ProductManagerSessionRemote
      {
      public <public <T extends PurchasableProduct> T loadPersonsOldestPurchasableProductOfType(
       T extends PurchasableProduct> T loadPersonsOldestPurchasableProductOfType(
       String personID, Class<T> purchasableProductClass, Status... statuses);
      }
      



      I notice that it appears as this in the server log when jboss is parsing it. Why is it transient?:
      public transient com.squaretrade.product2.PurchasableProduct com.squaretrade.product2.ProductManagerSessionImpl.loadPersonsOldestPurchasableProductOfType(java.lang.String,java.lang.Class,com.s
      quaretrade.enums.Status[])
      


      When I try and access a different method on the session bean I get the following error:
      java.lang.NoSuchMethodError: com.squaretrade.product2.ProductManagerSessionRemote.loadPersonsOldestPurchasableProductOfType(java.lang.String, java.lang.Class, [Lcom.squaretrade.enums.Status;)
       at $Proxy817.<clinit>(Unknown Source)
       at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
       at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
       at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
       at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
       at java.lang.reflect.Proxy.newProxyInstance(Proxy.java:588)
       at org.jboss.ejb3.proxy.impl.objectfactory.ProxyObjectFactory.redefineProxyInTcl(ProxyObjectFactory.java:351)
       at org.jboss.ejb3.proxy.impl.objectfactory.session.SessionProxyObjectFactory.createProxy(SessionProxyObjectFactory.java:134)
       at org.jboss.ejb3.proxy.clustered.objectfactory.session.SessionClusteredProxyObjectFactory.getProxy(SessionClusteredProxyObjectFactory.java:87)
       at org.jboss.ejb3.proxy.impl.objectfactory.ProxyObjectFactory.getObjectInstance(ProxyObjectFactory.java:158)
       at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:304)
       at org.jnp.interfaces.NamingContext.getObjectInstance(NamingContext.java:1479)
       at org.jnp.interfaces.NamingContext.getObjectInstanceWrapFailure(NamingContext.java:1496)
       at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:822)
       at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:686)
       at javax.naming.InitialContext.lookup(InitialContext.java:351)
       at com.squaretrade.locator.Locator.getSession(Locator.java:193)
       at com.squaretrade.product2.ProductManager.getManagerSession(ProductManager.java:1011)
       at com.squaretrade.product2.ProductManager.personHasPurchasableProductsOfType(ProductManager.java:431)
       at com.squaretrade.data.replication.DataReplicationQualifier.replicatePersonData(DataReplicationQualifier.java:100)
       at com.squaretrade.data.replication.AsynchDataReplicationProcessor.processPerson(AsynchDataReplicationProcessor.java:127)
       at com.squaretrade.admin.actions.CascadingDataRefresh.execute(CascadingDataRefresh.java:69)
       at com.squaretrade.struts.jboss.JBossAbstractAction.execute(JBossAbstractAction.java:71)
       at com.squaretrade.struts.AbstractActionBase.execute(AbstractActionBase.java:211)
       at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431)
       at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236)
       at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)
       at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414)
       at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
       at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
       at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
       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:235)
       at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
       at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
       at org.jboss.web.tomcat.service.session.ClusteredSessionValve.handleRequest(ClusteredSessionValve.java:135)
       at org.jboss.web.tomcat.service.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:94)
       at org.jboss.web.tomcat.service.session.LockingValve.invoke(LockingValve.java:62)
       at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
       at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
       at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
       at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
       at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
       at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
       at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
       at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
       at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:436)
       at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:384)
       at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
       at java.lang.Thread.run(Thread.java:595)
      


      This only seems to happen when accessing it from within the server. When I access it remotely from a JUnit test, it works fine.

      This used to work fine in jboss 4.0.5. I have tried this on both the java5 and java6 versions of the jboss 5.1.0 and get the same issue on both


        • 1. Re: Variable argument list in session bean method causes NoS
          jaikiran

          I thought we had covered this way back. We even have testcase for similar beans. Let me just try this and get back. And you are definitely using 5.1.0.GA right?

          • 2. Re: Variable argument list in session bean method causes NoS
            jaikiran

            Could not reproduce this. Can you provide more details about the packaging of your application? Is the bean deployed separately in a jar and the client web app in a independent war? Or are they packaged in a single ear? If you have a reproducible application, create a JIRA https://jira.jboss.org/jira/browse/EJBTHREE and attach the application with other details.

            • 3. Re: Variable argument list in session bean method causes NoS
              ablevine1

              I will try to get you a simplified example as soon as I can. How does your testcase work? We can get this to work when we call the session bean from a remote client, however when we call it from within our jboss server process, using either the local or remote session bean interface, we get the exception mentioned in the previous post. I would also like to note that we do not use dependency injection but rather use JNDI lookups to get references to our session beans in both cases.

              • 4. Re: Variable argument list in session bean method causes NoS
                jaikiran

                 

                "ablevine1" wrote:
                however when we call it from within our jboss server process, using either the local or remote session bean interface, we get the exception mentioned in the previous post. I would also like to note that we do not use dependency injection but rather use JNDI lookups to get references to our session beans in both cases.


                I tried a similar scenario (the bean the client in the same server) using lookup, worked fine. Feel free to provide a reproducible application.