1 2 Previous Next 29 Replies Latest reply: Jun 3, 2004 10:02 PM by Steve Lewis RSS

JCA in JB4/AOP

Steve Lewis Expert

I was wondering if you guys were planning any changes to the JCA infrastructure for JB4. Specifically, taking advantage of AOP to make things a little easier for people to write connectors.

I'm writing a proposal for something I've been thinking about that would use advisors to generate adapters at classload, given enough .xml.

Steve

  • 1. Re: JCA in JB4/AOP
    Nathan Egge Newbie

    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
    Steve Lewis Expert

    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
    Steve Lewis Expert

    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
    Andrew Oliver Master

    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 Master

    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
    Steve Lewis Expert

    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
    Steve Lewis Expert

    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 Master

    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
    Steve Lewis Expert

    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
    Steve Lewis Expert

    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
    Steve Lewis Expert

    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
    Steve Lewis Expert

    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 Master

    jbosspool is legacy stuff used in 2.4.x

  • 14. Re: JCA in JB4/AOP
    Adrian Brock Master

    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

1 2 Previous Next