Hi Clement,
On Wed, Oct 19, 2011 at 5:06 PM, Clement Escoffier <
clement.escoff...@gmail.com> wrote:
> Hi,
>
> On 19.10.2011, at 05:21, Göktürk Gezer wrote:
>
> > Hi Everyone,
> >
> > We're in the middle of moving our codebase to OSGI using IPojo. Problem
> is,
> > I can not instantiate the manipulated classes without IPojo.
> >
> > AFAIK, IPojo manipulates the constructors with no argument and
> BundleContext
> > argument. So we can use other constructors for instance creation without
> > getting through IPojo, and all field and method delegations will be
> disabled
> > in that case. Am i wrong?
>
> You're mostly right. iPOJO 'replaces' all constructors (since the 1.8.0
> because of the constructor injection support). However, original
> constructors are still existing, and accessible.
>
Yes, much more like it.
>
> So, if you have a class with:
> public class Foo {
>
> public String m_foo;
>
> public ConstructorCheck(String foo) {
> m_foo = foo;
> }
>
> }
>
> You will get:
> public ConstructorCheck(String s)
> {
> this(null, s);
> }
>
> private ConstructorCheck(InstanceManager _manager, String foo)
> {
> _setInstanceManager(_manager);
> __setm_foo(foo);
> }
>
> It means that you need to have iPOJO in your class path, but the semantic
> is not changed.
> (For information, __setm_foo(foo); will just do m_foo = foo; )
>
I have almost the same semantic, except generics involved.
>
> >
> > IPojoized classes are subclasses of some generic type, and i just use
> > @Component and @Provides on them. That's all, just for easy service
> > publication. But after that i can not instantiate them using
> _ctor(String)
> > constructor.
>
> Inheritance (using annotations on parent classes) is not yet supported.
> This is on the roadmap of iPOJO 2.0.
>
I'm not using it. But maybe i over modified files. Its about 30 classes, so
maybe i wrongly modified some parent. I'll look into that.
>
> >
> > If you ask why you're using normal instantiation, these usages without
> IPojo
> > are just on unit tests. Eventually we'll move these tests to OSGI, but it
> > would be cool to be able to still use them until we do.
> >
>
> I'm doing the same. So, avoid the inheritance, and it should work.
>
I'll go through it again with caution. Thanks.
>
> Regards,
>
> Clement
>
> >
> > Regards,
> > Gokturk
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
