[Design of JCA on JBoss] - Re: JcaXAResourceRecovery
by timfox
"adrian(a)jboss.org" wrote :
| Please raise a bug report, or better yet, fix it! :-)
|
Ok, I'll raise a report.
anonymous wrote :
| I hope your not planning to ask users to configure seperately JBoss Messaging
| recovery (and especially no seperate property files)?
|
| The aim is to try to make it zero configuration for recovery not asking them to configure
| things in 5 different places.
|
| I can understand supporting a seperate recovery plugin for standalone use
| of JBoss Messaging but NOT in the appserver please, it should be
| integrated via JCA!
|
For the app server we intend to use the JMSProvider based XAResourceRecovery, although it has the drawback of not being able to specify username and password as already mentioned on this thread.
The custom one, which uses it's own properties file is only currently used for the messaging bridge, which doesn't use JCA. Although I am coming around to the idea of deploying JCA with it too (the standalone bridge is really just a stripped down JBoss AS) then we can use the standard XAResource receovery.
We would like to have a "full" recovery solution for JBM before JBM 1.2 (at the end of the month) , which would need to include specifying a username and password. I don't know if the new JCA stuff is going to ready in time for that, so we may have no choice than to use our own properties file or maybe we can change the datasource to take recovery username/password params as you mention.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4009427#4009427
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4009427
18 years, 8 months
[Design the new POJO MicroContainer] - Re: Scoped beans deployment
by adrian＠jboss.org
"alesj" wrote : "adrian(a)jboss.org" wrote : If we/you can get some (semi) clear picture where and how we want this plumbing to happen, I can go and code some initial ideas - so that we can see what fits us best. And I can test this with our OSGi project (as previously mentioned requirement).
| |
|
| We discussed it a while ago (I think some of the major discussions were on
| the jboss-dev mailing list). I called it "policy" configuration at that time.
|
| If search worked I could find it for you. ;-)
|
| The basic idea is that you can deploy contextual metadata to scopes,
| underneath it would be something like:
|
|
| | <bean name="JCAPolicy" ...>
| | <annotation>scope definition</annotation>
| | <property name="binding">
| | <map>
| | bindings into the metadata scope go here
| | </property>
| | </bean>
| |
|
| But I wanted some easier xml than this, similar to the use case xml for AOP.
|
|
| | <policy>
| | <scope/>
| | <annotations/>
| | <bindings/>
| | </policy>
| |
| | |
| | | This then populates the MetaDataRepository for that scope.
| | | Something that is only done currently at the instance level for annotations
| | | against the bean.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4009426#4009426
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4009426
18 years, 8 months
[Design of POJO Server] - Re: Not keeping track of deployment class loader
by adrian＠jboss.org
"scott.stark(a)jboss.org" wrote :
| On startup we have a hack in the ProfileServiceBootstrap to take the first bootstrap DeploymentContext as the base TCL. I suppose the ShutdownHook should be going through the profile service to shutdown the deployments in phases and employ the same hack, but shouldn't there be an association in the ControllerContext to the install action class loader if it came from the TCL rather than the BeanMetaData?
|
The TCL switching does not exist in the Microcontainer (like it does in JMX).
I always believed this should be in an interceptor rather than in the "container"
since it should be optional behaviour.
In fact, this problem comes because of the HACK. What would really be
required is to inject the classloader into the Profile Service Bootstrap
deployment.
| <deployment>
| <classloader><inject bean="BootstrapClassLoader>/></classloader>
|
| <!-- More likely a factory! -->
| <bean name="BootstrapClassLoader">
| <!-- Obviously we can't use ourselves so use the caller -->
| <classloader><null/></classloader>
| </bean>
|
| <!-- Other beans heres -->
|
| </deployment>
|
But that isn't easy to do with the current way the classloaders get constructed
inside JMX.
It would however be trivial to remember the TCL that created the kernel controller context
(if there is nothing explicitly configured on the bean or deployment)
and switch to it during the (un)install actions.
This would be similar to the AccessControlContext code that restores the registering
context's security context for callouts.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4009421#4009421
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4009421
18 years, 8 months
[Design of JCA on JBoss] - Re: JcaXAResourceRecovery
by weston.price＠jboss.com
anonymous wrote :
| Your doing it all wrong. Read my previous comments.
|
Lovely. I actually won a bet. I bet someone at JBoss that you wouldn't post a response without saying something like this. Of course, given your nature I probably should have given him odds.
anonymous wrote :
| When JBossTS asks you to recover, you iterate over this repository and retrieve
| all the XAResources.
|
Ok, let's take a simple scenario:
JDBC based deployment using a security domain with a login config of CallerIdentityLoginModule. Just because the TxManager is deployed, doesn't mean the XAResource gets created. This comes off the underlying Connection which is only created when the pool is first used. So, what goes in the repository in this case? What do I iterate over during recovery?
How about a JDBC deployment that only support application-managed security? What if this is required information and can only be done via
getConnection(username,password)?
anonymous wrote :
| We discussed this nearly two years.
|
Well, unless you think my name is something other than Weston (which you actually seem completely incapable of remembering) we haven't. I have been here one year, and let me tell you I have loved every day!
The example you posted as a sample security configuration basically just offloads what would be in the external config file to the *-ds.xml, fine. I am not sure why you are listing a local-tx-datasource as these won't be supporting recovery, but no matter. So, I am assuming that your
| <recovery-security-domain>Recovery</recovery-security-domain>
|
is defined in login-config, so we have yet another piece of external information to 'kludge' this together it just happens to be in a 'comfortable' place that you are familiar with.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4009420#4009420
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4009420
18 years, 8 months
[Design of JCA on JBoss] - Re: JcaXAResourceRecovery
by adrian＠jboss.org
"timfox" wrote : Also, one thing I noticed when doing the XA recovery work for JBM is that the JMSProviderXAResourceRecovery instance that was done for JBossMQ is broken.
|
Please raise a bug report, or better yet, fix it! :-)
I hope your not planning to ask users to configure seperately JBoss Messaging
recovery (and especially no seperate property files)?
The aim is to try to make it zero configuration for recovery not asking them to configure
things in 5 different places.
I can understand supporting a seperate recovery plugin for standalone use
of JBoss Messaging but NOT in the appserver please, it should be
integrated via JCA!
The current JNDI provider based JMS recovery is half-way-house until
JCA does this properly.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4009407#4009407
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4009407
18 years, 8 months
[Design of JCA on JBoss] - Re: JcaXAResourceRecovery
by adrian＠jboss.org
Your doing it all wrong. Read my previous comments.
What you need is a repository of XA TxConnectionManagers and MDB
activations (these are setup by the deployments).
When JBossTS asks you to recover, you iterate over this repository and retrieve
all the XAResources.
All you need is a mechanism to get a link to this repository from your JBossTS
plugin. If JBossTS supported proper IOC configuration this would trivial,
instead you going to have to do some work.
Don't make the same mistake and introduce property files for your configuration!
The only configuration required is the security like you said.
We discussed this nearly two years. It is trivially solved by allowing
a connection factory or datasource to have two extra parameters to override
the default user or when it doesn't have a default user.
e.g.
| <local-tx-datasource>
| ...
| <recover-user>x</recovery-user>
| <recover-password>y</recovery-password>
|
| <!-- OR -->
|
| <recovery-security-domain>Recovery</recovery-security-domain>
| </local-tx-datasource>
|
You might also need a flag to say recovery cannot use (share) a
normal pooled connection since I know at least in the past some XAResources had
problems with normal operations after recover() is invoked.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4009406#4009406
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4009406
18 years, 8 months