[Design of EJB 3.0] - Re: EJB3 Classloader Leak (EJBTHREE-1442)
by wolfc
The proxy ends up in the ejb3-connectors class loader, which is wrong. This happens for every remote invocation.
This shows why:
Heap walker - Allocations
| Session: JBoss 5.x on localhost
| Time of export: Thursday, September 11, 2008 4:14:46 PM CEST
| JVM time: 83:33
|
| Current object set: 1 instance of java.lang.Class
| Selection steps: 4 selection steps, 16 bytes shallow size
|
| 0.0% - 0 bytes - 0 alloc. org.jboss.remoting.transport.socket.ServerThread.run
| 0.0% - 0 bytes - 0 alloc. org.jboss.remoting.transport.socket.ServerThread.dorun
| 0.0% - 0 bytes - 0 alloc. org.jboss.remoting.transport.socket.ServerThread.processInvocation
| 0.0% - 0 bytes - 0 alloc. org.jboss.remoting.transport.socket.ServerThread.completeInvocation
| 0.0% - 0 bytes - 0 alloc. org.jboss.remoting.ServerInvoker.invoke
| 0.0% - 0 bytes - 0 alloc. org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke
| 0.0% - 0 bytes - 0 alloc. org.jboss.aop.Dispatcher.invoke
| 0.0% - 0 bytes - 0 alloc. java.lang.reflect.Method.invoke
| 0.0% - 0 bytes - 0 alloc. org.jboss.ejb3.proxy.factory.session.SessionProxyFactoryBase.createProxyBusiness
| 0.0% - 0 bytes - 0 alloc. org.jboss.ejb3.proxy.factory.ProxyFactoryBase.createProxyConstructor
| 100.0% - 16 bytes - 1 alloc. java.lang.Class.getConstructor
The proxy should have ended up in the same class loader as the business interface. That's the job of the ObjectFactory.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4175879#4175879
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4175879
17 years, 7 months
[Design of JBoss jBPM] - Unifying jBPM project lifecycles
by thomas.diesler@jboss.com
Folks,
after internal discussions we came to the conclusion that it would simplify the development cycle of both jbpm3 and 4 a great deal if we would actually talk about these to development branches as such.
In Jira, SVN, Maven we would have jbpm-3.3.x and jbpm-4.0.x releases. Both project branches would align their release cycle, so that consumers of these projects can rely on updates in the maven repository approximately every 8 weeks.
The distinction between pvm, jpdl4 lifecycle is superfluous because for the foreseeablr future both projects evolve lock step anyway. For jBPM users it will also become easier, because in future you will only need to refer to jbpm-x.y.z without needing to make a distinction in project name based on component.
The pvm release artefact in the maven repository will of course stay decoupled as is for folks that only want to consume the pvm base component.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4175869#4175869
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4175869
17 years, 7 months