[Design of EJB 3.0] - Re: EJBTHREE-1669 : @Service tutorial on JBoss-5.0 GA
by jaikiran
"jaikiran" wrote :
| Let me give it a try with the plugin against the AS trunk.
This fails on AS5 trunk, with a different exception (NPE):
16:13:15,776 INFO [JBossASKernel] installing bean: tutorial:service=ServiceOne
| 16:13:15,776 INFO [JBossASKernel] with dependencies:
| 16:13:15,776 INFO [JBossASKernel] and demands:
| 16:13:15,776 INFO [JBossASKernel] jboss.j2ee:jar=jboss-ejb3-tutorial-service.jar,name=ServiceOne,service=EJB3
| 16:13:15,776 INFO [JBossASKernel] jboss.ejb:service=EJBTimerService
| 16:13:15,776 INFO [JBossASKernel] and supplies:
| 16:13:15,776 INFO [JBossASKernel] Class:org.jboss.tutorial.service.bean.ServiceOneManagement
| 16:13:15,776 INFO [JBossASKernel] jndi:ServiceOne/remote
| 16:13:15,776 INFO [JBossASKernel] Class:org.jboss.tutorial.service.bean.ServiceOneLocal
| 16:13:15,776 INFO [JBossASKernel] Class:org.jboss.tutorial.service.bean.ServiceOneRemote
| 16:13:15,776 INFO [JBossASKernel] jndi:ServiceOne/local-org.jboss.tutorial.service.bean.ServiceOneLocal
| 16:13:15,776 INFO [JBossASKernel] jndi:ServiceOne/local
| 16:13:15,777 INFO [JBossASKernel] jndi:ServiceOne/remote-org.jboss.tutorial.service.bean.ServiceOneRemote
| 16:13:15,777 INFO [JBossASKernel] Installing bean(tutorial:service=ServiceOne) into kernel
| 16:13:15,849 ERROR [AbstractKernelController] Error installing to Create: name=jboss.j2ee:jar=jboss-ejb3-tutorial-service.jar,name=ServiceOne,service=EJB3 state=Configured
| java.lang.RuntimeException: Problem registering @Management interface for @Service class org.jboss.tutorial.service.bean.ServiceOne
| at org.jboss.ejb3.service.ServiceContainer.registerManagementInterface(ServiceContainer.java:779)
| at org.jboss.ejb3.service.ServiceContainer.create(ServiceContainer.java:251)
| 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 org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
| at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
| at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
| at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:241)
| at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
| at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:109)
| at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:70)
| at org.jboss.kernel.plugins.dependency.LifecycleAction.installActionInternal(LifecycleAction.java:221)
| at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54)
| at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42)
| at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
| at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
| at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
| at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
| at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:774)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
| at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:121)
| at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:51)
| at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
| at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
| at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
| at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598)
| at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
| at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:545)
| at org.jboss.system.server.profileservice.hotdeploy.HDScanner.scan(HDScanner.java:290)
| at org.jboss.system.server.profileservice.hotdeploy.HDScanner.run(HDScanner.java:221)
| at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417)
| at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:280)
| at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:135)
| at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:65)
| at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:142)
| at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:166)
| at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
| at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
| at java.lang.Thread.run(Thread.java:595)
| Caused by: java.lang.RuntimeException: javax.management.MBeanException
| at org.jboss.ejb3.deployers.JBossASKernel.installMBean(JBossASKernel.java:181)
| at org.jboss.ejb3.service.ServiceContainer.registerManagementInterface(ServiceContainer.java:757)
| ... 54 more
| Caused by: javax.management.MBeanException
| at org.jboss.ejb3.service.ServiceMBeanDelegate.invoke(ServiceMBeanDelegate.java:219)
| at org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:164)
| at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
| at org.jboss.ejb3.deployers.JBossASKernel.invokeOptionalMethod(JBossASKernel.java:287)
| at org.jboss.ejb3.deployers.JBossASKernel.installMBean(JBossASKernel.java:176)
| ... 55 more
| Caused by: javax.ejb.EJBException: java.lang.NullPointerException
| at org.jboss.ejb3.tx.Ejb3TxPolicy.handleExceptionInOurTx(Ejb3TxPolicy.java:77)
| at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:83)
| at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:190)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
| at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
| at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
| at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
| at org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
| at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
| at org.jboss.ejb3.service.ServiceContainer.localInvoke(ServiceContainer.java:512)
| at org.jboss.ejb3.service.ServiceContainer.localInvoke(ServiceContainer.java:475)
| at org.jboss.ejb3.service.ServiceMBeanDelegate.invoke(ServiceMBeanDelegate.java:215)
| ... 59 more
| Caused by: java.lang.NullPointerException
| 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 org.jboss.aop.joinpoint.MethodInvocation.invokeTarget(MethodInvocation.java:122)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
| at org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:56)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
| at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
| at org.jboss.ejb3.tx.NullInterceptor.invoke(NullInterceptor.java:42)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
| at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
| ... 74 more
|
The populateInvocation method is setting a null beanContext:
protected StatefulContainerInvocation populateInvocation(StatefulContainerInvocation invocation)
| {
| invocation.setBeanContext(beanContext);
| return invocation;
| }
|
When is the beanContext expected to be created?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4200935#4200935
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4200935
17 years, 2 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: servlet transport implementation
by ataylor
here's a bit more of a detailed explanation to how this will work. This will be implemented in netty as discussed in irc.
A ServletContextListener will create a ClientBootstrap on startup. This will be configured via properties, probably read in from a config file with some sensible defaults. This will be added as an attribute to the ServletTransport. It would be cool if netty had an invm client bootstrap to use however in the absence of this it will be a normal socket connection. Trustin, currently would there be any way of doing this invm?
An HttpSessionListener will be used to create a connection for each session. Since netty doesn't support cookies at the minute we will have to manually check the headers to pull out the session id and add it as a parameter for all further requests. Also at this point we'll set the pipeline factory before creating the connection. a seperate instance of a 'ServletChannelHandler will be set for each connection. Both the Channel and the ServletChannelhandler will be added to the session as attributes.
The ServletChannelHandler will work 2 ways. On MessageReceived it will either 1) store the received buffers to be returned by the next http request (polling) or 2) write directly to the ServletOutputStream (streaming).
The Servlet itself will decode the http request body and forward it via the channel previously set on the session. It will then set the appropriate headers on the response and return as the body any awaiting responses if using the polling method.
>From a client side we'll be able to reuse most of what we already have. maybe just a few changes for using sessions and for streaming.
Trustin, how would you like me to package the servlet classes etc. Also i'll include some sample web.xml configurations etc so where should i put these?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4200922#4200922
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4200922
17 years, 2 months
[Design of EJB 3.0] - PU Injection across JARs (unrelated DeploymentUnits)
by ALRubinger
Failing is "org.jboss.ejb3.test.hbm.unit.EntityUnitTestCase.testAll".
Use case is 2 JARs, one declaring a PU and the other has EJBs that want to inject this PU. The JARs are deployed independently (not part of an EAR).
I've been tinkering with a patch that will enable resolution of PUs no matter where they've been deployed:
Index: deployers/src/main/java/org/jboss/jpa/resolvers/DefaultPersistenceUnitDependencyResolver.java
| ===================================================================
| --- deployers/src/main/java/org/jboss/jpa/resolvers/DefaultPersistenceUnitDependencyResolver.java (revision 82757)
| +++ deployers/src/main/java/org/jboss/jpa/resolvers/DefaultPersistenceUnitDependencyResolver.java (working copy)
| @@ -21,8 +21,11 @@
| */
| package org.jboss.jpa.resolvers;
|
| +import java.util.Collection;
| +
| import org.jboss.beans.metadata.api.annotations.Inject;
| import org.jboss.deployers.structure.spi.DeploymentUnit;
| +import org.jboss.ejb3.common.deployers.spi.Ejb3DeployerUtils;
| import org.jboss.jpa.javaee.JavaEEModuleInformer;
| import org.jboss.metadata.jpa.spec.PersistenceMetaData;
| import org.jboss.metadata.jpa.spec.PersistenceUnitMetaData;
| @@ -48,6 +51,36 @@
| String unitName = (appName != null ? appName + "/" : "") + modulePath + "#" + persistenceUnitName;
| return "persistence.unit:unitName=" + unitName;
| }
| +
| + /**
| + * Attempts to find the PU with specified persistence unit name
| + * in any of the EJB3 DeploymentUnits registered with the Main
| + * Deployer. Returns the first eligible found.
| + *
| + * @param persistenceUnitName
| + * @return
| + */
| + private String findWithinMainDeployer(String persistenceUnitName)
| + {
| + // Get all deployment units
| + Collection<DeploymentUnit> dus = Ejb3DeployerUtils.getAllEjb3DeploymentUnitsInMainDeployer();
| +
| + // For each DU
| + for(DeploymentUnit du:dus)
| + {
| + // Attempt to find
| + String name = this.findWithinApplication(du, persistenceUnitName);
| +
| + // If found, return
| + if(name!=null)
| + {
| + return name;
| + }
| + }
| +
| + // Not found
| + return null;
| + }
|
| private String findWithinApplication(DeploymentUnit unit, String persistenceUnitName)
| {
| @@ -137,6 +170,8 @@
| String name = findWithinModule(deploymentUnit, persistenceUnitName, true);
| if(name == null)
| name = findWithinApplication(deploymentUnit.getTopLevel(), persistenceUnitName);
| + if(name==null)
| + name = this.findWithinMainDeployer(persistenceUnitName);
| if(name == null)
| throw new IllegalArgumentException("Can't find a persistence unit named '" + persistenceUnitName + "' in " + deploymentUnit);
| return name;
But the above does not address the issue of dependencies.
PersistenceUnitDeployments are installed into MC using a bean name that takes the JAR/EAR name into account. Some arbitrary EJB wanting to inject the PU therefore cannot declare a dependency upon the MC bean name, as it doesn't know (or care) which DeploymentUnit is going to supply the PU.
Thoughts?
Also it looks like one of our users is running into this: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4200880
S,
ALR
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4200883#4200883
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4200883
17 years, 2 months
[Design of JBoss Remoting, Unified Invokers] - Re: Remoting 2: Servlet Invoker
by ron.sigal＠jboss.com
Hi A,
This is an amazing coincidence. I've just been working on JBPAPP-1274 "Fix JBoss Messaging and JBoss Remoting so that servlet transport can be used", for which I've been trying to get a single client to make EJB2, EJB3, and JBM invocations over the servlet transport. I've got EJB3 and JBM working, and just a couple of hours ago I was working on an EJB2 invocation. Unfortunately, the proxy is, for some reason, using the socket transport.
Anyway, as for the jar sizes, I just built a jboss-remoting.jar with jdk1.5.0_06 and jdk1.5.0_15 and got 1047846 and 1046394 bytes, respectively, so that's a possible explanation. But there's something strange about your line numbers - they don't match what I see under https://svn.jboss.org/repos/jbossremoting/remoting2/tags/2.5.0.SP2. Don't know what's going there.
Here's how the servlet transport works. org.jboss.remoting.transport.servlet.web.ServerInvokerServlet gets the invocation and ServerInvokerServlet.processRequest() calls org.jboss.remoting.transport.servlet.ServletServerInvoker.processRequest(), where it's the latter method that isn't being found. When ServerInvokerServlet is initialized, it gets either the ObjectName or the InvokerLocator of the ServletServerInvoker it's supposed to use. In the latter case it gets a reference to the actual ServletServerInvoker, so I doubt you'd see an "Unable to find operation" exception in that case. If ServerInvokerServlet gets an ObjectName, then it makes invocations on an MBean proxy, which is what I guess is happening. So, the question is, what ObjectName are you initializing ServerInvokerServlet in your web.xml file?
Note that in Remoting 2.2.x, every ServletServerInvoker has the same ObjectName: "jboss.remoting:service=invoker,transport=servlet". But in Remoting 2.4+, the ObjectNames for ServletServerInvokers are created by
| public String getMBeanObjectName()
| {
| InvokerLocator locator = getLocator();
| StringBuffer buffer =
| new StringBuffer("jboss.remoting:service=invoker,transport=" + locator.getProtocol());
| String host = locator.getHost();
| boolean isIPv6 = host.indexOf("[") >= 0 | host.indexOf(":") >= 0;
|
| buffer.append(",host=");
| if (isIPv6)
| buffer.append("\"");
| buffer.append(locator.getHost());
| if (isIPv6)
| buffer.append("\"");
|
| buffer.append(",port=").append(locator.getPort());
| Map param = locator.getParameters();
| if(param != null)
| {
| Iterator itr = param.keySet().iterator();
| while(itr.hasNext())
| {
| buffer.append(",");
| String key = (String) itr.next();
| String value = (String) param.get(key);
| buffer.append(key);
| buffer.append("=");
| buffer.append(value);
| }
| }
|
| return buffer.toString();
| }
|
So, for example, the ObjectName for the EJB2 servlet invoker I'm playing with right now is "jboss.remoting:dataType=invocation,host=127.0.0.1,marshaller=org.jboss.invocation.unified.marshall.InvocationMarshaller,port=8080,return-exception=true,service=invoker,transport=servlet,unmarshaller=org.jboss.invocation.unified.marshall.InvocationUnMarshaller".
Does that help? By the way, I didn't even know there was a servlet test in the EJB3 test suite. I'll take a look at that. But not tonight. :)
-Ron
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4200821#4200821
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4200821
17 years, 2 months