-
1. Re: JCA in JB4/AOP
negge Apr 16, 2004 8:56 AM (in response to spiritualmechanic)Right you are. They aren't mutually exclusive.
Right now I'm just trying to familiarize myself with JCA and JBoss's implementation of JCA, so I can think correctly about going about this "simplification." -
2. Re: TODO: ConnectionDefinitionDeployer - replace XSLSubDeplo
spiritualmechanic Apr 16, 2004 8:56 AM (in response to spiritualmechanic)How does the XSLSubDeployer tell the MainDeployer that it's a necessary SubDeployer? I see the addDeployer(SubDeployer) but I don't see where it's called to add the XSL.
I'm just tracing through the code of XSLSubDeployer starting with its createService() method, but I don't see how its init(DeploymentInfo) method is called. Does something else register XSLSubDeployer
OH. There it is. Parent class SubDeployerSupport has the mainDeployer. Duh.
RARDeployer extends SubDeployerSupport, so instead of using XSLSubDeployer we want ConnectionFactoryDeployer to extend SubDeployerSupport as well.
Who creates a DeploymentInfo object? Is it something that is created when a file is found under the deploy directory?
I'll keep looking :) Maybe I'm a masochist, but I'm actually enjoying this. -
3. Re: JCA in JB4/AOP
spiritualmechanic Apr 16, 2004 8:56 AM (in response to spiritualmechanic)Adrian,
I can send you my JCPool mbean if you want to look at the code, to see if I'm on the right track, or if I'm missing any obvious features.
If you don't want to, or don't have time, or just have better things to do, that's fine as well :D I'll send it on whenever I have the AOP part working, then, all wrapped together.
Steve -
4. Re: JCA in JB4/AOP
acoliver Apr 16, 2004 8:56 AM (in response to spiritualmechanic)You don't want to use finalize() it isn't guaranteed to be called and even if does get
called, it wrecks gc performance.
A real solution would be to do caller side analysis/weaving:
i.e.
POJOResource pr = new POJOResource;
pr.doSomething();
becomes (pseudo code)
POJOResource pr = POJOResourceManager.get();
try
{
pr.doSomething();
}
finally
{
POJOResourceManager.release(pr);
}
But this requires a fair bit of analysis of the bytecode.
A simpler solution would be to assume the resource has a close() method
and that it is called by the client. You would just identify the close operation
in the metadata.
The handles are just "proxies".
Regards,
Adrian -
5. Re: JCA in JB4/AOP
adrian.brock Apr 16, 2004 10:04 AM (in response to spiritualmechanic)An interesting idea. A lot of the work in resource adapters follows a number of
patterns and is just boilerplate code.
Are you thinking of something like:/** * @jca:manageable */ public class POJOResource { ... }
Yes, it is already on our list to add aspects/interceptors to the JCA implementation in
JBoss4 so you can plugin your own behaviour. This is scheduled for after
the JBoss4 beta release when we have finished the required j2ee1.4 spec work.
Regards,
Adrian -
6. Re: JCA in JB4/AOP
spiritualmechanic Apr 16, 2004 10:38 AM (in response to spiritualmechanic)Yes, exactly.
But also like (I don't know xdoclet but you'll get the idea)
/**
* @jca:pooled
* @jca:secure
* @jca:subject
* @jca:internalsync/externalsync (i.e. JDBC-like or JMS-like, respectively)
* @jca:makehandlesongetters (recurse tree of objects, so you're using handles, never directly hitting the resource itself)
*/
public class POJOResource
Obviously, the person JCA-ing their resource would have to know, but the probability of messing up will be because of real issues, not because someone forgot to write close correctly, or whatever.
Steve -
7. Re: JCA in JB4/AOP
spiritualmechanic Apr 16, 2004 10:41 AM (in response to spiritualmechanic)Here's what I blogged earlier this morning.
JCA is a pain. It's complex, it's subtle, and it's easy to mess up. A better solution would be to define an advisor for any resouce, and generate the necessary JCA interfaces/managedconnections/factories behind the scenes at classload time.
This would work for
* JDBC
* JMS
* Mail
* HTTP
* Any other resource you want pooled and secure.
So far the necessary issues that would have to be addressed in an .xml file would be:
* Internally synchronized or externally synchronized
Not only could you wrap the resource, you could wrap any Foo (the client retrieval via the resource's getFoo() ). The entire resource graph could be wrapped, similar to how Connection and Statement are wrapped in the current JBossCX implementation.
This would allow anyone to turn client code into server code instantly. -
8. Re: JCA in JB4/AOP
adrian.brock Apr 16, 2004 11:31 AM (in response to spiritualmechanic)Here's a challenge for you: implement it :-)
Adding resource pooling to a pojo with no transaction or security injection would be a proof
of concept.
Don't worry about the quality of the code, we can tidy that up later with a real
implementation. -
9. Re: JCA in JB4/AOP
spiritualmechanic Apr 16, 2004 12:10 PM (in response to spiritualmechanic)That is the plan. I'm working on a JCA adapter for the jboss-mail project, but once I'm done with that I'm going to start working on this.
I need to start picking up JBoss-AOP, so now I have a good excuse :D
Steve -
10. Re: JCA in JB4/AOP
spiritualmechanic Apr 16, 2004 12:53 PM (in response to spiritualmechanic)Adrian,
Do you know the state of the jbosspool project in CVS? If it's old and not used, I'll just mock up a quick one myself.
Steve -
11. Re: JCA in JB4/AOP
spiritualmechanic Apr 16, 2004 1:28 PM (in response to spiritualmechanic)It's very minimal, tech oriented. Mostly it's just links to interesting things that I've found, cuz I hate using bookmarks in browsers.
Steve -
12. Re: JCA in JB4/AOP
spiritualmechanic Apr 16, 2004 1:58 PM (in response to spiritualmechanic)Just thinking out loud here. Don't mind me.
Intercept the constructor. Instead of just returning an instance, look up from the pool (say an ArrayList) the first unused instance. Set a flag to say it's in use and return the instance.
Intercept the finalize(). In the AOP-all example there's an extra set of "Entering../Leaving.." output, so maybe it's using the finalize or something. That's really the closest thing we have to a deconstructor in Java, which should be fine, since that's where you're supposed to close any resources anyways.
Figure out what to call when a method is called. Should we directly call the method on the object? The idea that JCA uses is that of handles, so you're never directly pointing to the actual resource object.
Steve -
13. Re: JCA in JB4/AOP
adrian.brock Apr 16, 2004 2:00 PM (in response to spiritualmechanic)jbosspool is legacy stuff used in 2.4.x
-
14. Re: JCA in JB4/AOP
adrian.brock Apr 16, 2004 2:10 PM (in response to spiritualmechanic)You don't want to use finalize() it isn't guaranteed to be called and even if does get
called, it wrecks gc performance.
A real solution would be to do caller side analysis/weaving:
i.e.
POJOResource pr = new POJOResource;
pr.doSomething();
becomes (pseudo code)
POJOResource pr = POJOResourceManager.get();
try
{
pr.doSomething();
}
finally
{
POJOResourceManager.release(pr);
}
But this requires a fair bit of analysis of the bytecode.
A simpler solution would be to assume the resource has a close() method
and that it is called by the client. You would just identify the close operation
in the metadata.
The handles are just "proxies".
Regards,
Adrian