RE: Are iPOJO objects really POJOs

[Clement Escoffier <cl...@gmail.com>]

> 
> 
> 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: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org

Re: Are iPOJO objects really POJOs

["Richard S. Hall" <he...@ungoverned.org>]

For a simple example, if you had a component like this:

public class MyComponent {
    private LogService log;
    public MyComponent() {
    }
    public MyComponent(LogService log) {
        this.log = log;
    }
    public void doBusinessLogic()
    {
        log.log(LogService.INFO, "Business logic called.");
        // Do business logic.
    }
}

If you were to use this component outside of iPOJO, you could use the 
constructor to inject the dependency, but when use inside of iPOJO then 
the empty constructor would be used. The component should function the 
same in either case. Note, if you only plan to use the component in 
iPOJO, then you don't need a constructor at all, since the default one 
will be sufficient.

Perhaps some confusion comes from the byte code manipulation. In any 
approach that uses byte code manipulation, you have two steps:

   1. Compile the component to get your class file.
   2. Manipulate the class file to get your instrumented class file.

(1) is not dependent on the container, clearly. (2) has dependencies on 
the container in every approach (although these dependencies might not 
break the component, as in the case of iPOJO). In all approaches, there 
is a particular time in which (2) occurs.

Some approaches do this at run time, so if you are outside of the 
container you don't see any modifications at all. For a variety of 
technical reasons that provide various benefits, iPOJO does (2) at 
packaging time. Thus, your packaged component is actually steps 1 + 2 
above. Thus, if you really want to use your component without iPOJO at 
all, you probably shouldn't run it through iPOJO's packaging step. Even 
then, this shouldn't cause any problems.

-> richard

Clement Escoffier wrote:
>> 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: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>   

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org