> > > Hi everybody, > > Having played a little with iPojo, at a first glance I think that > objects manipulated by iPOJO are no plain objects at all ! Playing with > private fields simply prevents the code of a so-called POJO to be > tested by JUNIT or to be used without the iPOJO container. The object > must be designed to be used in the iPojo container, this is in my view > contrary to the orginal definition of a POJO !
The component class is a POJO, once manipulated it's no more a POJO as it becomes attached to the iPOJO container model. However, once manipulated, the POJO can use their fields as normal fields. If not managed by the iPOJO container, fields are treated "normally". To test your component with Junit, either you run your tests before manipulation, either you provide a constructor or setter methods injecting values inside your component fields (if they should be managed by the container). > Moreover, if you have a security manager, I don't think changing > methods or fields accessibility, or manipulating bytecode would > generally be considered acceptable. Bytecode manipulation does not throw security exception and does not change accessibility of fields and methods. However, I agree with method invocation through reflection. That's why the accessibility is checked before set. If you choose to use private callback to inject a value and you have a security manager restricting reflection, it can't work. > > Apparently field and method injection is only a feature in iPojo. Are > you thinking of providing a version of iPojo without this feature, or > is it considered essential ? > The bytecode manipulation on which the iPOJO runtime relies is essential to attach component objects (pojo objects) to the container. However, you can use only method injection (methods are then called by reflection as the SCR bind / unbind methods). So, your fields are treated normally, and are not delegated to the container. However, you have to worry about synchronization (managed by the container during field injection) and to be sure to release service objects when the provider is unbound. Clement --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
