Mailing-List: contact users-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@felix.apache.org
Received-SPF: pass (nike.apache.org: domain of gokturk.gezer@gmail.com
 designates 209.85.160.177 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <2F8C0EF8-472C-462A-9A77-843AAB978907@gmail.com>
References: 
 <CAKjwzkp1c=1Lg=ugaa0NQkN2Q21_H9OQtrYBC1kGEQSpyac62Q@mail.gmail.com>
	<2F8C0EF8-472C-462A-9A77-843AAB978907@gmail.com>
Date: Wed, 19 Oct 2011 20:13:53 +0300
Message-ID: 
 <CAKjwzkqFxWUjuAAGkzNzj8EQq31z-A=gdQamAyGfS_3sTj-vzQ@mail.gmail.com>
Subject: Re: Instantiating Manipulated Class without IPojo
From: =?UTF-8?B?R8O2a3TDvHJrIEdlemVy?= <gokturk.gezer@gmail.com>
To: users@felix.apache.org
Content-Type: multipart/alternative; boundary=bcaec521549fe656d604afa9f6ba

--bcaec521549fe656d604afa9f6ba
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Clement,

On Wed, Oct 19, 2011 at 5:06 PM, Clement Escoffier <
clement.escoffier@gmail.com> wrote:

> Hi,
>
> On 19.10.2011, at 05:21, G=C3=B6kt=C3=BCrk 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 withou=
t
> > 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 =3D 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 =3D 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-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>

--bcaec521549fe656d604afa9f6ba--