[Design of JBoss Transaction Services] - Re: beanifying the config
by ben.cotton＠rutgers.edu
"jhalliday" wrote : In an effort to better accommodate the assorted bean-centric configuration and dependency wiring frameworks (e.g. Spring, MC) I'm considering further changes to the way TS internals are configured.
|
| [... snip ...]
|
| What I'd like to do is introduce a per-module EnvironmentBean,
|
| [... snip ...]
|
|
Interesting re: the consideration to "accommodate ... assorted ... dependency wiring frameworks".
1. Do any current (or past considered) parts of the TS internals' code make use of DI Singleton Beans?
2. If answer to #1 is "Yes", is it true that those TS Singleton Beans are bound exclusively to the Spring framework API (as its lone DI provider)?
3. Would the implementation of the new per-module EnvironmentBeans give any priority to considering non-Spring DI APIs (especially e.g. Guice)?
4. Is there any value (beyond academic) to considering a "DI-provider independent" approach to building these (and potentially future) TS Singleton Beans?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4246049#4246049
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4246049
16 years, 8 months
[Design of EJB 3.0] - Quartz MDB integration and classloader issues
by jaikiran
There have been more than a couple of users now, having trouble with getting the Quartz integration with MDB running. Here are the 2 instances, for example:
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=158926
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4229808
The real issue is classloading where the quartz thread triggers a job. The QuartzJob which does this (and is triggered through quartz-ra.rar) has the base classloader which does not have access to user deployment classloader. So if you have your MDB packaged in a deployment with its own classloader (which is practical), then the QuartzJob will not have access to the EJBs in the user deployment leading to exceptions like:
| javax.ejb.EJBTransactionRolledbackException: Unable to inject jndi dependency: env/org.jboss.tutorial.quartz.bean.AnnotatedQuartzMDBBean/calc into property org.jboss.tutorial.quartz.bean.AnnotatedQuartzMDBBean.calc: org.jboss.tutorial.quartz.bean.Calculator from BaseClassLoader@1f172aa{VFSClassLoaderPolicy@9f3364{name=vfszip:/home/jpai/jboss-5.1.0.GA/server/default/deploy/quartz-ra.rar/ domain=ClassLoaderDomain@1f5eb7f{name=DefaultDomain parentPolicy=BEFORE parent=org.jboss.bootstrap.NoAnnotationURLClassLoader@1431340} roots=[MemoryContextHandler@31918682[path= context=vfsmemory://3j001-a542up-fxj4w94o-1-fxj4x19a-21 real=vfsmemory://3j001-a542up-fxj4w94o-1-fxj4x19a-21], DelegatingHandler(a)22593168[path=quartz-ra.rar context=file:/home/jpai/jboss-5.1.0.GA/server/default/deploy/ real=file:/home/jpai/jboss-5.1.0.GA/server/default/deploy/quartz-ra.rar], DelegatingHandler(a)21430906[path=quartz-ra.rar/quartz-ra.jar context=file:/home/jpai/jboss-5.1.0.GA/server/default/deploy/ real=file:/home/jpai/jboss-5.1.0.GA/server/default/deploy/quartz-ra.rar/quartz-ra.jar]] delegates=null exported=[META-INF, org.jboss.resource.adapter.quartz.inflow] <IMPORT-ALL>NON_EMPTY}}
| at org.jboss.ejb3.tx.Ejb3TxPolicy.handleInCallerTx(Ejb3TxPolicy.java:115)
| at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:130)
| at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:194)
| 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.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:80)
| 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.mdb.MessagingContainer.localInvoke(MessagingContainer.java:282)
| at org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.delivery(MessageInflowLocalProxy.java:270)
| at org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.invoke(MessageInflowLocalProxy.java:140)
| at $Proxy136.execute(Unknown Source)
| at org.jboss.resource.adapter.quartz.inflow.QuartzJob.execute(QuartzJob.java:57)
| at org.quartz.core.JobRunShell.run(JobRunShell.java:203)
| at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:520)
| Caused by: java.lang.RuntimeException: Unable to inject jndi dependency: env/org.jboss.tutorial.quartz.bean.AnnotatedQuartzMDBBean/calc into property org.jboss.tutorial.quartz.bean.AnnotatedQuartzMDBBean.calc: org.jboss.tutorial.quartz.bean.Calculator from BaseClassLoader@1f172aa{VFSClassLoaderPolicy@9f3364{name=vfszip:/home/jpai/jboss-5.1.0.GA/server/default/deploy/quartz-ra.rar/ domain=ClassLoaderDomain@1f5eb7f{name=DefaultDomain parentPolicy=BEFORE parent=org.jboss.bootstrap.NoAnnotationURLClassLoader@1431340} roots=[MemoryContextHandler@31918682[path= context=vfsmemory://3j001-a542up-fxj4w94o-1-fxj4x19a-21 real=vfsmemory://3j001-a542up-fxj4w94o-1-fxj4x19a-21], DelegatingHandler(a)22593168[path=quartz-ra.rar context=file:/home/jpai/jboss-5.1.0.GA/server/default/deploy/ real=file:/home/jpai/jboss-5.1.0.GA/server/default/deploy/quartz-ra.rar], DelegatingHandler(a)21430906[path=quartz-ra.rar/quartz-ra.jar context=file:/home/jpai/jboss-5.1.0.GA/server/default/deploy/ real=file:/home/jpai/jboss-5.1.0.GA/server/default/deploy/quartz-ra.rar/quartz-ra.jar]] delegates=null exported=[META-INF, org.jboss.resource.adapter.quartz.inflow] <IMPORT-ALL>NON_EMPTY}}
| at org.jboss.injection.JndiPropertyInjector.lookup(JndiPropertyInjector.java:82)
| at org.jboss.injection.JndiPropertyInjector.inject(JndiPropertyInjector.java:99)
| at org.jboss.injection.JndiPropertyInjector.inject(JndiPropertyInjector.java:89)
| at org.jboss.injection.JndiPropertyInjector.inject(JndiPropertyInjector.java:61)
| at org.jboss.ejb3.injection.InjectionInvocation.invokeTarget(InjectionInvocation.java:89)
| at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:83)
| at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
| at org.jboss.ejb3.injection.InjectionInvocation.invokeNext(InjectionInvocation.java:74)
| at org.jboss.ejb3.EJBContainer.injectBeanContext(EJBContainer.java:1097)
| at org.jboss.ejb3.pool.AbstractPool.create(AbstractPool.java:83)
| at org.jboss.ejb3.pool.AbstractPool.create(AbstractPool.java:73)
| at org.jboss.ejb3.pool.StrictMaxPool.get(StrictMaxPool.java:146)
| at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:58)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
| at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
| ... 17 more
| Caused by: javax.naming.NamingException: Could not dereference object [Root exception is javax.naming.NamingException: Could not dereference object [Root exception is java.lang.RuntimeException: Can not find interface declared by Proxy in our CL + BaseClassLoader@1f172aa{vfszip:/home/jpai/jboss-5.1.0.GA/server/default/deploy/quartz-ra.rar/}]]
| at org.jnp.interfaces.NamingContext.resolveLink(NamingContext.java:1352)
| at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:817)
| at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:686)
| at org.jboss.ejb3.JndiUtil.lookup(JndiUtil.java:44)
| at org.jboss.injection.JndiPropertyInjector.lookup(JndiPropertyInjector.java:75)
| ... 31 more
| Caused by: javax.naming.NamingException: Could not dereference object [Root exception is java.lang.RuntimeException: Can not find interface declared by Proxy in our CL + BaseClassLoader@1f172aa{vfszip:/home/jpai/jboss-5.1.0.GA/server/default/deploy/quartz-ra.rar/}]
| at org.jnp.interfaces.NamingContext.getObjectInstanceWrapFailure(NamingContext.java:1504)
| 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 org.jnp.interfaces.NamingContext.resolveLink(NamingContext.java:1346)
| ... 35 more
| Caused by: java.lang.RuntimeException: Can not find interface declared by Proxy in our CL + BaseClassLoader@1f172aa{vfszip:/home/jpai/jboss-5.1.0.GA/server/default/deploy/quartz-ra.rar/}
| at org.jboss.ejb3.proxy.impl.objectfactory.ProxyObjectFactory.redefineProxyInTcl(ProxyObjectFactory.java:343)
| at org.jboss.ejb3.proxy.impl.objectfactory.session.SessionProxyObjectFactory.createProxy(SessionProxyObjectFactory.java:134)
| at org.jboss.ejb3.proxy.impl.objectfactory.session.stateless.StatelessSessionProxyObjectFactory.getProxy(StatelessSessionProxyObjectFactory.java:79)
| 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)
| ... 39 more
|
Looking at the code, i think the right way to fix this is to change the org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.delivery to deliver the message as part of the container's classloader:
| Index: src/main/java/org/jboss/ejb3/mdb/inflow/MessageInflowLocalProxy.java
| ===================================================================
| --- src/main/java/org/jboss/ejb3/mdb/inflow/MessageInflowLocalProxy.java (revision 91150)
| +++ src/main/java/org/jboss/ejb3/mdb/inflow/MessageInflowLocalProxy.java (working copy)
| - return delivery(proxy, container, method, args);
| + {
| + ClassLoader earlierClassLoader = Thread.currentThread().getContextClassLoader();
| + try
| + {
| + // Deliver the message through the container's classloader
| + Thread.currentThread().setContextClassLoader(container.getClassloader());
| + return delivery(proxy, container, method, args);
| + }
| + finally
| + {
| + Thread.currentThread().setContextClassLoader(earlierClassLoader);
| + }
| +
| + }
| }
|
|
Thoughts? Anything obviously wrong with this approach?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4245976#4245976
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4245976
16 years, 8 months
[Design the new POJO MicroContainer] - Abstract Beans JBKERNEL-10
by marius.bogoevici
I added a prototype (read partial) implementation for Abstract Beans, and uploaded the patch in Jira (JBKERNEL-10).
What I did was:
- introduce a new ControllerMode called ABSTRACT
- install abstract beans as controller contexts with ABSTRACT mode, which are never progressing past the DESCRIBED state
- modify the initialVisitor to merge parent data with current bean data (i.e. copy metadata from parent if missing in child or merge if it is a collection - this allows child beans to override parent bean settings).
Copying metadata from parent to child works - what needs to be done is to make sure that this is done in a semantically correct way for all types of metadata, for eliminating ambiguities.
One issue I encountered is that metadata such as PropertyMetaData is stored in a Set in the BeanMetaData, yet PropertyMetaData does not implement equals() and hashCode().
This leads to the possibility of writing definitions such as:
| <bean ... >
| <property name="someProperty">Value1</property>
| <property name="someProperty">Value2</property>
| </bean>
|
, and given that both elements will generate a PropertyMetaData and they will be stored in a HashSet, it is hard to tell which one of the two will be used to set the value when the bean is instantiated.
Currently, merging the two property sets (parent and child) can produce a similar effect, if the same property is defined in the parent and child. It is possible to elliminate duplicates in the merging process,but the main challenge is in making this process generic.
Using an implementation for equals() that is based on PropertyMetaData.getName() would be a poor hack, since it is hard to say that two PropertyMetaData instances having the same name but different values are equal. I am currently considering using a Map for the merging process, and we might use something similar inside AbstractBeanMetaData.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4245973#4245973
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4245973
16 years, 8 months