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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
