Discussions

News: CGLIB 2.0 Final Release

  1. CGLIB 2.0 Final Release (27 messages)

    The cglib has released a 2.0 final version of its popular code generation library. cglib is used behind the scenes in many tools and frameworks, such as Hibernate, Spring, dynaop, Nanning, and many more. The final release fixed some security issues, and optimizations.

    cglib Home Page

    Download cglib 2.0 final

    Threaded Messages (27)

  2. Overview Helpful[ Go to top ]

    There's a decent overview of what CGLIB does buried in its Javadocs:

    http://cglib.sourceforge.net/apidocs/net/sf/cglib/proxy/Enhancer.html

    It took me a few minutes to find it, which reminds me of a frustration I have with Javadocs - it's often difficult to tell the difference between packages that are purely implementation oriented, and packages that contain the API for end users.
  3. More docs are needed[ Go to top ]

    My #1 TODO for CGLIB for a long time now is to improve the documentation. While the javadocs are improving, a tutorial and examples are sorely needed. I'm sure any contributions in this area would be greatly appreciated by a lot of people. FWIW here is a breakdown of the packages:

      n.s.cglib.proxy -- interception
      n.s.cglib.reflect -- faster reflection, C#-style delegates
      n.s.cglib.util -- Collections-oriented utilities
      n.s.cglib.beans -- JavaBean utilities (BeanMap, etc.)
      n.s.cglib.transform -- on- and off-line classfile tranformations
      n.s.cglib.core -- low-level bytecode core (ASM stuff)

    Chris
  4. More docs are needed[ Go to top ]

    At http://www.kgionline.com/articles/aop_1/aop1.jsp I have described my experiments with some AOP tools with emphasis on CGLIB and near real life example of this library usage. Today we successfully use CGLIB in our project to implement transaction management and greatly simplify DAO code.

    I highly recommend this wonderful library.
  5. More docs are needed[ Go to top ]

    Konstantin, that is an excellent article. thanx.
    I am confused about how you think using transactions
    in this manner is clearer code? Transactions are only
    needed at certain places. I don't see how inserting
    transaction code automatically at the method level
    matches real world usage. If i have an operation
    that adds to 4 different tables, i want the transaction
    logic in that operation, not the methods doing the
    individual adds.
  6. More docs are needed[ Go to top ]

    I don't see how inserting transaction code automatically at the method level matches real world usage.


    If we look at the source code of my example then we see that Connection object is propagated via ThreadLocal variable and on the last screenshot we may see that Transaction starts when we call a first DAO method and when this method calls other DAO methods then all of them use the came connection object and the same transaction

    >> I am confused about how you think using transactions in this manner is clearer code?
    Because DAO code does not have try-catch-finally scattered everywhere anymore. Proxy class takes care of those details in one place.
    So our DAO code looks like this:

    MyMethod() throws Exception{
      Connection cn = Env.getCurrentConnectionOrCreateNewOne();
      …do our work here…
    }

    So the class is aware of the fact that it will be instrumented at runtime, which is not pure AOP but work great for me.
  7. More docs are needed[ Go to top ]

    Konstantin, your example code sounds like an ad-hoc version of what the Spring Framework provides via its generic transaction management, with declarative transaction demarcation via AOP.

    Have you actually checked out Spring's support in that respect? Various transaction strategies are included out-of-the-box (JTA, JDBC, Hibernate, JDO), and pre-integrated with various data access strategies (JDBC, iBATIS SQL Maps, Hibernate, JDO). Transaction demarcation can happen programmatically or declaratively.

    Spring binds resources like JDBC Connections and Hibernate Sessions to ThreadLocals too, to be looked up via DataSourceUtils.getConnection respectively SessionFactoryUtils.getSession, or automatically by JdbcTemplate or HibernateTemplate. Such DAO code will be able to work with any transaction strategy, including JTA.

    Furthermore, Spring also provides generic (unchecked) exception hierarchies for transaction management exceptions and data access exceptions, effectively allowing to decouple DAO interfaces from specific data access strategies.

    Juergen
  8. More docs are needed[ Go to top ]

    sounds like an ad-hoc version of what the Spring Framework provides via its generic..


    Yes it is.

    I checked Spring FW, but decided not to use it because:
    1. It looks as too broad attempt to address too many aspects simultaneously (to be a container and MVC and something else is too much at my taste). Therefore:
    - I did not have much confidence in the overall quality, simply because of its size: more code, more room for bugs;
    - Broad coverage means that FW has general design ideas which may not be compatible with current system design and/or implementation;
    - XML descriptors for various things;
    2. I have great confidence in CGLIB itself because it works great in Hibernate;
    3. I prefer Pico container and its ideology.

    Silly reason:) I hate web sites with are not resizable and I have to read tiny pages on my huge screen.

    More seriously: Spring might be fine when somebody starts a new project, but ad-hoc seemed preferable at that time because I did refactoring of only Hibernate DAO layer.

    Please note: I posted link to my example only as a real CGLIB use case and I do not recommend my type of solution in general
  9. CGLIB is flamewar agnostic[ Go to top ]

    In a probably futile effort to keep this discussion on track, I would like to point out that the Spring framework does use CGLIB to allow its AOP layer to work against concrete classes. I'm happy to help any project integrate CGLIB if they so desire--I do have my personal architecture preferences but prefer to keep them secret :-)

    Chris
  10. CGLIB is flamewar agnostic[ Go to top ]

    I had no slightest desire to start FW wars and just tried to explain why I have used CGLIB directly, rather than via some FW.

    >>but prefer to keep them secret :-)
    Sorry to hear about it. It is extremely interesting for me to hear what other people prefer. This way I noticed CGLIB, some people prefer it and have used in their projects (Hibernate, Spring, etc.)
  11. CGLIB is flamewar agnostic[ Go to top ]

    No problem, I wasn't addressing it to anyone in particular. It is just very uncommon for a thread where one of Spring/Pico/Webwork/Tapestry/etc is mentioned that does not spin out of control :-) I'm very glad to see your article about CGLIB and hope it is the first of many!!!

    Chris
  12. CGLIB is flamewar agnostic[ Go to top ]

    I found proxies are very usefull for data access code too. I do not use proxies for transaction demarcation and resource management(there are more trivial ways).
    Proxy can be usefull to cache method result, declarative authorization, it can be used to publish plain interfaces for RPC too.
    This way is not limited for interception, it can be used to implement method itself (without concrete classes). Most of data access methods I have ever saw
    do something like this:
    <pre>
     MyResluts method(MyParam param)throws MyExeption{
         //getConnection or PersistenceManager
        ...............
       try{

          //prepare statement or "Query"
          ....................
          //set or "Bind" parameters
          ...................
          //execute
          ..........
          //copy data to MyResluts

        }catch(...){
        //handle or rethrow data acces exceptions
        ....................
      }finally{
        //close local resources
        ..................
      }

     }
    </pre>
     
    There is no "business logic" and there is nothing to code (it can be generated).
    I use cglib to implement data acces code in http://voruta.sourceforge.net

    server side RPC has no "business logic" too:


     MyResluts method(MyParam param)throws MyExeption,RemoteExeption{

       return myDAO.method(param);

     }

    There is incomplete example in voruta, it demonstrates how to use single session bean with single remote method to publish data access services (it can be used as portable way to implement interception for EJB without any standard too)
  13. More docs are needed[ Go to top ]

    I checked Spring FW, but decided not to use it because:

    > 1. It looks as too broad attempt to address too many aspects simultaneously (to be a container and MVC and something else is too much at my taste). Therefore:
    > - I did not have much confidence in the overall quality, simply because of its size: more code, more room for bugs;
    > - Broad coverage means that FW has general design ideas which may not be compatible with current system design and/or implementation;
    > - XML descriptors for various things;
    > 2. I have great confidence in CGLIB itself because it works great in Hibernate;
    > 3. I prefer Pico container and its ideology.

    That choice is fine, of course. Unfortunately, Spring's scope sometimes irritates people; we're doing everything to clarify things in that respect. Interesting that you call PicoContainer an "ideology", though ;-)

    I don't intend to have a in-depth discussion here; just a general note: Spring is a strictly layered framework, so for example the web framework is just an option. Many people adopt is as middle tier framework; we also provide fine-grained module-specific jars as of RC1. And XML bean definitions are just an option too: There are various other options, including programmatic registration.

    > More seriously: Spring might be fine when somebody starts a new project, but ad-hoc seemed preferable at that time because I did refactoring of only Hibernate DAO layer.

    That sounds reasonable to me! I didn't intend to criticize your solution; I just noticed the analogous basic idea and wanted to ask whether you actually know about Spring's solution. Spring certainly adopts a more generic approach here; of course, whatever works for you is good :-)

    And now back to CGLIB!

    Juergen
  14. More docs are needed[ Go to top ]

    I didn't intend to criticize your solution;

    You are always welcome to criticize. It is beneficial not just for me but might help others clarify where and when one solution is more appropriate then another.
  15. use for EJB?[ Go to top ]

    thanks, for this article.

    something like CGLib this is exactly, what i am looking for. Small and unintrusive.

    however, i would like to use it for EJB SessionBeans. Is it possible to use this library for EJB?

    TIA, Heinz-Dieter Conradi
  16. use for EJB?[ Go to top ]

    I am not sure what you mean saying "for EJB SessionBeans".

    I use it _within_ SessionBeans with no problems. Please write directly to me and I will try to help, may be all you need is just a slightly modified XDoclet’s SessionBean generation pattern.
  17. use for EJB?[ Go to top ]

    I'm not exactly sure what you're looking for, but the OpenEJB project is using CGLIB 2.0 to improve the performance of their EJB implementation.

    Chris
  18. use for EJB?[ Go to top ]

    thanks, for this article.

    >
    > something like CGLib this is exactly, what i am looking for. Small and unintrusive.
    >
    > however, i would like to use it for EJB SessionBeans. Is it possible to use this library for EJB?
    >
    Yes, the way described in article must work with SessionBeans, but it will have
    some code dublication (delegation from remote method to DAO).
    You can generate this stuff with cglib too.

    Idea is very simple, use single Bean with single method for application (front controler)

    interface Server extends EJBObject{
      
      public Object invoke( Class DAOClassName,
                            String methodName,
                            Class paramTypes[] ,
                            Object args[]) throws RemoteException, Exception;
          

    }
    implemention is trivial, reflection or CGLIB reflect package for perfomance.
    client is a proxy object, it can be CGLIB or JDK proxy.

    I have experimented with both Stateles and Statefull beans,
    looks like Statefull are better for transactions.
    I do not use this way for production at this time (I have no new projects with EJB), but it must be very simple to implement and to use, it must reduce
    XML garbage (single bean in application), it must easy to mock or to use all DAO as local object after reconfiguration or local plain interfaces as remote.
    Design and code must be very clear (removes code dublication).

    This is my experiment:
    http://voruta.sourceforge.net/xref/samples/ejb/package-summary.html
    This sample can be broken, but must be easy fix or rewrite to remove dependancies on voruta and use your way to implement DTO, I generate DTO
    implementation with cglib too.

    > TIA, Heinz-Dieter Conradi
  19. use for EJB?[ Go to top ]

    Sorry for off topic.
    >> it must reduce XML garbage (single bean in application), it must easy to mock or to use all DAO as local object after reconfiguration or local plain interfaces as remote.
    >>Design and code must be very clear (removes code duplication).

    Looks like good plan for wasting a lot of time. Just look at http://xdoclet.sourceforge.net/ . It does all that was advised but better: no need to deal with XML garbage, no need to develop proxy classes etc.

    It is all just done and well tested at productionÂ…
  20. use for EJB?[ Go to top ]

    Sorry for off topic.

    > >> it must reduce XML garbage (single bean in application), it must easy to mock or to use all DAO as local object after reconfiguration or local plain interfaces as remote.
    > >>Design and code must be very clear (removes code duplication).
    >
    > Looks like good plan for wasting a lot of time. Just look at http://xdoclet.sourceforge.net/ . It does all that was advised but better: no need to deal with XML garbage, no need to develop proxy classes etc.
    >
    > It is all just done and well tested at productionÂ…

    I am not sure about this way and I use Xdoclet too, but I think I will try it next time. I hope it will be even more clear (I think it something wrong in architecture if I need to generate source code and metadata)
  21. use for EJB?[ Go to top ]

    something like CGLib this is exactly, what i am looking for. Small and unintrusive.

    > >
    > > however, i would like to use it for EJB SessionBeans. Is it possible to use this library for EJB?
    > >
    > Yes, the way described in article must work with SessionBeans, but it will have
    > some code dublication (delegation from remote method to DAO).
    > You can generate this stuff with cglib too.
    >
    > Idea is very simple, use single Bean with single method for application (front controler)
    >
    > interface Server extends EJBObject{
    >
    > public Object invoke( Class DAOClassName,
    > String methodName,
    > Class paramTypes[] ,
    > Object args[]) throws RemoteException, Exception;
    >
    >
    > }

    thanks, i have thought along the same lines.
    nevertheless, i would prefer a solution, without a central controller class which has to be used bye the client. one disadvantage, of that is the lost type savefty. whereas in the example with the CGLib the client sees no difference.

    i guess, i have to look a bit more carefully. e.g. for something like JBossAOP.
  22. use for EJB?[ Go to top ]

    Why do you think there is some problems with type safety ?
    Clients see "normal" interface, without "invoke" :
     MyUserManager canBeRemote = proxyFactory.create(MyUserManager.class);

    BTW Jboss implements all remote Beans this way too (single proxy for all interfaces). It is very easy to implement "at home" 2-3 hours and it will work on any container or without it.
  23. use for EJB?[ Go to top ]

    MyUserManager canBeRemote = proxyFactory.create(MyUserManager.class);

      
    OK, it is much clearer now what you mean. Yes, the implementation is workable and might be even convenient at times, however:
    - I would translate “for EJB” as “for implementing an EJB based RPC protocol”, which defines meaning of the proposed process;
    - The proposed approach requires some undefined ways to communicate server API to the client. I mean that this approach is roughly equivalent using Object as method parameter, i.e. any object can be passed but there is no guarantee that the method accepts this object. Of course there might be an agreement on what package defines contract etc., but ….all I am saying that is less exact than using definitive API;
    - >> something wrong with architecture if it requires metadata…
    I am not so sure, although I would agree that J2EE triad plus meta seems overcomplicated ( I favor CORBA approach: IDL as a medium and server and client are free to do what ever they like). In the same time I see some sense in the basic ideas behind J2EE and would rather take advantage of XDoclet conveniences then dismiss J2EE and proclaim that I know a better way.

    - this approach requires implementing of some kind of life cycle management on server side (Pico container?), when EJB comes with defined life cycle, which might be well suitable ( especially after a while).
    - With definite EJB API nowadays servers allows other ways of calling EJB (CORBA and SOAP-RPC), which might not be necessary now but who knows…
  24. use for EJB?[ Go to top ]

    Probaly it is not very clear, but it the same as EJB.
    All objects will be Stateles if Controler on server is Stateles and all are Statefull if Controler is Statefull (You can have two controlers if you need both).
     Standard way for transaction propagation is used too (delegated for JTA API). Controler is transparent for client, client side factory returns type safe objects "invoke" is used for implementation only.
    1.
    Client see and call this interface:

    interface UserManager{
       
        boolean authenticate(String userName,String password)

    }
    2.
    proxyFactory creates proxy object for MyUserManager on client:
    MyUserManager canBeRemote = proxyFactory.create(MyUserManager.class);
    3.
    proxyFactory lookups "Server" Session bean and creates server instance for internal use (for delegation).
    4. client calls:

     if( canBeRemote.autehnticate(usr,psw)){

    }
    5. Proxy on client intercepts methods and delegates for "Server.invoke".
    6. Server Bean implementation lookups interface implementation and invokes the real method (It can any interface so it can bee standard Bean with standard methods too). It is possible to use JNDI for lookup in both sides too.


    This API is transparent for client and server code. Most of Containers I have ever saw implement EJB this way, see some stack trace from weblogic and how it distributes beans ( If this way is not safe, containers bust be not safe too).
    You do not loose any EJB features (interfaces can be registread as Beans and have the same metadata as before), but you have interception for client and server code without container specific AOP, so you can integrate any AOP framework this way, use POJO or you can do some crazzy things :)

    BTW There is almost no changes to add interception for existig code, you need
    to add a few lines of code to bean factory method on client side.





    > >> MyUserManager canBeRemote = proxyFactory.create(MyUserManager.class);
    >   
    > OK, it is much clearer now what you mean. Yes, the implementation is workable and might be even convenient at times, however:
    > - I would translate “for EJB” as “for implementing an EJB based RPC protocol”, which defines meaning of the proposed process;
    > - The proposed approach requires some undefined ways to communicate server API to the client. I mean that this approach is roughly equivalent using Object as method parameter, i.e. any object can be passed but there is no guarantee that the method accepts this object. Of course there might be an agreement on what package defines contract etc., but ….all I am saying that is less exact than using definitive API;
    > - >> something wrong with architecture if it requires metadata…
    > I am not so sure, although I would agree that J2EE triad plus meta seems overcomplicated ( I favor CORBA approach: IDL as a medium and server and client are free to do what ever they like). In the same time I see some sense in the basic ideas behind J2EE and would rather take advantage of XDoclet conveniences then dismiss J2EE and proclaim that I know a better way.
    >
    > - this approach requires implementing of some kind of life cycle management on server side (Pico container?), when EJB comes with defined life cycle, which might be well suitable ( especially after a while).
    > - With definite EJB API nowadays servers allows other ways of calling EJB (CORBA and SOAP-RPC), which might not be necessary now but who knows…
  25. More docs are needed[ Go to top ]

    Amen. CGLIB is really powerful but because there is no documentation, it takes a while to get up and going. Add good doco and u will see traffic increase exponentially (not to mention increased bug reports and fixes)
  26. CGLIB 2.0 Final Release[ Go to top ]

    Hi all,

    I've noticed CGLIB 2.0 release yesterday morning, and it took me less then half a day to integrate CGLIB into our current project to support declarative transactions on a top of existing transaction support (or should I say transaction aspect).
    CGLIB is realy great and simple to use.

    Mileta
  27. CGLIB 2.0 Final Release[ Go to top ]

    Am I wrong or JavaDoc download for CGLIB 2.0 final is broken ?
  28. CGLIB 2.0 Final Release[ Go to top ]

    Am I wrong or JavaDoc download for CGLIB 2.0 final is broken ?

    Yes, it is broken.
    Thank you, I will update this jar.