[Design of POJO Server] - Contract ejb3-interceptors and bean-factory
by wolfc
I'm having a serious regression issue in ejb3-interceptors where interceptor instances are no longer bound to an EJB lifecycle, but to the container instead.
Basically there is no way to store the interceptors per bean instance. So to preserve the StatelessObjectFactory API I build ejb3-attachments, which allows for attaching interceptor instances to a bean.
(Note: that the problem does not occur in 'basic' (AOP) operation of ejb3-interceptors, because then the 'PER_INSTANCE' advice is correctly picked up by AOP. So in effect the 'PER_INSTANCE' advice isn't handled correctly by the interceptor BeanContainer (or ManagedAdvisor). If we want to move more AOP then the real fix is to have a proper instance advisor.)
The main problem with attachments is that passivation needs to be aware. Which is precisely what I not want.
Beyond scope for this discussion: pool (which is a consumer of the bean factory) and injection (which is a facilitator within the bean factory). The injection of interceptors I want to handle in a separate thread.
Maybe we need an InstanceContext / BeanContext from the StatelessObjectFactory:
Factory<T> {
| BeanContext<T> create();
| };
|
| BeanContext<T> {
| T getInstance();
|
| <A> A getAttachment(Object key, Class<A> attachmentType);
| }
Does MC have such a thing?
(Note 2: the current ejb3-interceptors also calls PostConstruct on the bean, which I think is wrong (it's JSR-250 functionality, not EJB 3 ch 8), however the ejb3-interceptors component needs a visitor hook in bean-factory to allow for attachment / interceptors construction (via the same bean-factory?)).
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140136#4140136
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140136
16 years
[Design of POJO Server] - Re: migrating TransactionManager and Invokers to POJO
by jhalliday
Another week, another exciting chapter in the migration saga...
I remove the transaction manager mbean from transaction-service.xml and put a bean in transaction-bean.xml instead:
<?xml version="1.0" encoding="UTF-8"?>
| <deployment xmlns="urn:jboss:bean-deployer:2.0">
| <bean name="TransactionManager" class="com.arjuna.ats.jbossatx.jta.TransactionManagerService">
| <property name="transactionTimeout">300</property>
| <property name="objectStoreDir">${jboss.server.data.dir}/tx-object-store</property>
| </bean>
| </deployment>
|
That works ok, the bean is instantiated and create is called on it. Woohoo.
Then lots of things break, because they depend on "jboss:service=TransactionManager", so I try to persuade my shiny new POJO to cross-dress as a JMX mbean:
<?xml version="1.0" encoding="UTF-8"?>
| <deployment xmlns="urn:jboss:bean-deployer:2.0">
|
| <bean name="MBeanExporter" class="org.jboss.system.microcontainer.jmx.ServiceControllerLifecycleCallback">
| <property name="serviceController"><inject bean="JMXKernel" property="serviceController"/></property>
| </bean>
| <bean name="TransactionManager" class="com.arjuna.ats.jbossatx.jta.TransactionManagerService">
| <annotation>@org.jboss.aop.microcontainer.aspects.jmx.JMX(name="jboss:service=TransactionManager", exposedInterface=com.arjuna.ats.jbossatx.jta.TransactionManagerServiceMBean.class, registerDirectly=true)</annotation>
|
| <property name="transactionTimeout">300</property>
| <property name="objectStoreDir">${jboss.server.data.dir}/tx-object-store</property>
|
| <install bean="MBeanExporter" method="install">
| <parameter><inject fromContext="context"/></parameter>
| </install>
| <uninstall bean="MBeanExporter" method="uninstall">
| <parameter><inject fromContext="context"/></parameter>
| </uninstall>
| </bean>
|
| </deployment>
|
So now I get two copies of the transaction manager bean instantiated. Huh? I want one instance, not two. Where the heck did the other one come from? I guess perhaps I've not expressed the desired config properly? I want one object behaving as both a bean and an mbean, not two separeate objects. Is there some other way of achieving that?
I also have problems because some things are not happening in the right order. Before either create or start is called on the transaction manager bean I see something that depends on it being started. Huh? This does not follow my understanding of the lifecycle, which is that dependent objects should not move into a state until everything they depend on has achieved at least an equivalently advanced state. Does the required state need to be specified explicitly on the CachedConnectionManager? Or perhaps this behaviour is something to do with the CCM being an mbean whilst the TM is a bean?
14:22:54,750 ERROR [AbstractKernelController] Error installing to Start: name=jboss.jca:service=CachedConnectionManager state=Create mode=Manual requiredState=Installed
| java.lang.ExceptionInInitializerError
| at org.jboss.resource.connectionmanager.CachedConnectionManager.startService(CachedConnectionManager.java:191)
| ...
| Caused by: java.lang.RuntimeException: Unable to locate the transaction manager
| at org.jboss.tm.TransactionManagerLocator.locate(TransactionManagerLocator.java:105)
| ...
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140135#4140135
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140135
16 years
[Design the new POJO MicroContainer] - Re: Parsing more than one file
by alesj
"adrian(a)jboss.org" wrote :
| 2) Being able to parse multiple files with the same suffix from META-INF.
|
| e.g.
| META-INF/a-beans.xml
| META-INF/b-beans.xml
|
| should create two KernelDeployment attachments (with the attachment names
| as the metadata url).
|
| But this requires the deployers further down the chain to understand it.
| i.e. not use getAttachments(KernelDeployment.class) but use
| getAllAttachments(KernelDeployment.class) and handle the multiple pieces
| of configuration correctly.
This is done.
KernelDeploymentDeployer already handles KernelDeployments in such way - getAllMetaData(KernelDeployment.class).
"adrian(a)jboss.org" wrote :
| 1) Being able to parse n files into one piece of metatdata from one parsing deployer
|
| This is so you can deploy something programmatically properly.
| e.g. You pass EjbJarMetaData. The current parsing deployers will say,
| ok I'm not going to reparse ejb-jar.xml but I will reparse jboss.xml
| which is wrong
|
This probably requires change into AbstractParsingDeployerWithOutput, to take more than one name?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140134#4140134
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140134
16 years
[Design of JBoss Build System] - Re: Move dependency management back into app server svn stru
by adrian＠jboss.org
"wolfc" wrote : I've got a nice analogy now: go back to Paul's original post and substitute 'component-matrix' with 'Hibernate' or 'jboss-logging' or any other common component.
|
| The arguments presented by Paul will still hold up, yet we do not want these things in the AS trunk.
That's a logical fallacy, in fact probably a few of them. :-)
I only have to do the exercise proposed to see its not true.
anonymous wrote :
| After spending some time updating dependencies in the HIBERNATE pom while working on the build-thirdparty conversion, it seems that having ... HIBERNATE as a separate project is somewhat error prone.
|
| The main issue is that whenever I make a change in ... HIBERNATE I have to make sure that the app server is immediately updated to match, otherwise there are build errors.
|
Which plainly isn't true.
There's a big difference between an external project that is included in JBossAS
as a component and an external project that actually defines what
those components should be.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140133#4140133
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140133
16 years
[Design of JBoss Build System] - maven-metadata.xml and 'mvn release:perform'
by dimitris＠jboss.org
While doing a jboss-common-core release, the following maven-metadata.xml was updated:https://svn.jboss.org/repos/repository.jboss.org/maven2/org/jboss...
a) I can see version 2.2.3.GA missing. Given this one was used by other components, I conclude the maven-metadata.xml is not always necessary?
b) Anyone knows if ordering is important?
c) What's the meaning of v2.0.5.GA as it is recorded below?
After a quick search, I didn't much about the maven-metadata schema.
| <?xml version="1.0" encoding="UTF-8" ?>
| <metadata>
| <groupId>org.jboss</groupId>
| <artifactId>jboss-common-core</artifactId>
| <version>2.0.5.GA</version>
| <versioning>
| <release>2.2.4.GA</release>
| <versions>
| <version>2.0.5.GA</version>
| <version>2.2.2.GA</version>
| <version>2.2.1.GA</version>
| <version>2.2.4.GA</version>
| </versions>
| <lastUpdated>20080328111223</lastUpdated>
| </versioning>
| </metadata>
|
Another problem I noticed is the moment you are doing the 'mvn release:perform' you need to have checked all the versions of a component, in-order to get access to the maven-metadata.xml, so the new version is correctly added. That means a lot of garbage in your local filesystem, just to do a simple release.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140104#4140104
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140104
16 years