[Design of JCA on JBoss] - Re: JcaXAResourceRecovery
by adrian＠jboss.org
With the MC in JBoss5 we could do something like the following:
NOTE: I allow mutlple XAResources because of the ResourceAdapter
http://java.sun.com/j2ee/1.4/docs/api/javax/resource/spi/ResourceAdapter....
But it would be the job of our Resource Adapter deployment to add
the known activation specs, i.e. those that have been activated.
| package org.jboss.tm; // in jboss integration
|
| public interface XAResourceRecovery
| {
| XAResource[] getXAResources();
| }
|
You would then have methods:
| public void addXAResourceRecovery(XAResourceRecovery recovery) {}
| public void removeXAResourceRecovery(XAResourceRecovery recovery) {}
|
The wiring can then either be done manually (including programmatically - see MBeans below)
| <bean "MyConnectionManager" ...>
| <install bean="TMService" method="addXAResourceRecovery">
| <parameter><this/></parameter>
| </install>
| <uninstall bean="TMService" method="removeXAResourceRecovery">
| <parameter><this/></parameter>
| </uninstall>
| </bean>
|
or "automagically" by you asking to be injected with any bean
that implements the interface.
| <bean name="TMService" ...>
| <incallback method="addXAResourceRecovery"/>
| <uncallback method="addXAResourceRecovery"/>
| </bean>
|
The automagic approach is less error prone, but doesn't work with MBeans.
LEGACY
For the old MBeans it would have to do something like:
| <mbean ...>
| <attribute name="TMService><inject bean="TMService"/></attribute>
|
| public void startService() throws Exception
| {
| getTMService().addXAResourceRecovery(this);
| }
| public void stopService() throws Exception
| {
| getTMService().removeXAResourceRecovery(this);
| }
|
IMPLEMENTATION AND SECURITY
The construction of the XAResource (including the injection
of a "Recovery Subject" from the security config - see above) would
be handled by whoever implements the XAResourceRecovery.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133205#4133205
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133205
16 years, 6 months
[Design the new POJO MicroContainer] - Update the relevant .classpath files
by alesj
>From this sticky thread:
- http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133184#4133184
"adrian(a)jboss.org" wrote :
| 2) Update the relevant .classpath files
|
| ...
|
| (2) is optional, but it would be friendly, otherwise we end up with different
| subprojects referencing different versions (e.g. because only one uses a new feature)
| and Eclipse gets confused when running tests or showing source.
|
Rather than friendly, I see this as unnecessary.
OK, I guess this was very useful for the projects that didn't have Maven handling the build or any other means of producing the project files.
I know I would like to have something like that for AS_trunk and IntelliJ. ;-)
But in our case, it's nothing more than additional work.
Not to sound rude, but why should we care about .classpath files and not any other IDE project files?
I bet there is a Maven --> (your) IDE plugin available, so let's all use that and drop those .classpath files.
Not to mention that if we still decide to support them, we're bypassing what Maven poms actually hold as dependencies, possibly resulting in inconsistency between poms and .classpath.
I'm always in favor of not keeping things around that can be generated.
And we're doing that with javacc, so why the change-of-heart here? ;-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4133189#4133189
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4133189
16 years, 6 months