Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (athena.apache.org: domain of jgawor@gmail.com designates
 209.85.132.250 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=iuIKYvO7lNYE8MGeYOrBy3foYd6VVuUQyICqQczwA+jFyyOLtmq1git2GbTBqwogwY
         zhAMwdFsm27ldyEOPUk6ZpyVf72SqHz4CWaGKJ2I3roLtQOjMb+s6OwbRMkS6sD/tJgI
         GeTADCt5KRXDRO6P6mvLeHz139ArwzKm3zsok=
MIME-Version: 1.0
In-Reply-To: <b23ecedc0904131449l23f9eb07pa4005f8c6ed47bfe@mail.gmail.com>
References: <19e0530f0903170558s2048dd2cy1ca802639fb7c9b5@mail.gmail.com>
	 <49D3462E.70401@gmail.com>
	 <5eb405c70904081023p5b0c82cfoe14c3b11245e0c74@mail.gmail.com>
	 <49E33A2E.50808@gmail.com>
	 <b23ecedc0904130708u6e704581t3356dfbc8592fcf7@mail.gmail.com>
	 <b23ecedc0904131151p65917b56u43f1892c44637c18@mail.gmail.com>
	 <5eb405c70904131317m2b940a40kc79df4c1dd469bb9@mail.gmail.com>
	 <b23ecedc0904131449l23f9eb07pa4005f8c6ed47bfe@mail.gmail.com>
Date: Mon, 13 Apr 2009 18:06:04 -0400
Message-ID: <5eb405c70904131506l35760bb8wf2feb613bf2cb9a3@mail.gmail.com>
Subject: Re: [OSGi] Support for RFC 124?
From: Jarek Gawor <jgawor@gmail.com>
To: dev@geronimo.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Either way works for me. First, I would rather stay with the API
classes and interfaces defined by the spec (I was working of the draft
3 of the specification). Second, I do like Rick's deep copy
constructor. I would like to keep it even if it's not being
used/needed now. But we can always add that later.

So go ahead and merge my code into yours and put the new code
somewhere directly under the sandbox and we'll start working from
there. In the mean time, I'll work on some other aspects of the spec
while you merge this stuff.

Thanks,
Jarek

On Mon, Apr 13, 2009 at 5:49 PM, Guillaume Nodet <gnodet@gmail.com> wrote:
> I agree that we need to join forces.
> Actually, i have started experimenting with xbean-refect after having
> seen your code :-)
>
> If we are going to use generics in the implementation, it may be
> easier to use the reflect package implementation classes that i wrote.
> Anyway, I think the main difference is that the one Rick wrote allow
> deep copy of values with a copy constructor. =A0Rick, have you seen such
> a need anywhere in the spec ? =A0While implementing the parser, I
> haven't seen the need for it so I wonder if we need to keep that or
> not.
> The parser has dependencies on those classes, so we need to merge /
> refactor here.
>
> I'm currently working on integrating your code into mine, but we could
> do the opposite if you prefer.
>
> On Mon, Apr 13, 2009 at 22:17, Jarek Gawor <jgawor@gmail.com> wrote:
>> On Mon, Apr 13, 2009 at 2:51 PM, Guillaume Nodet <gnodet@gmail.com> wrot=
e:
>>> Btw, I'm not so sure iPojo is a good candidate for implementing the
>>> blueprint service.
>>> I've began doing some testing with xbean-reflect and I am able to
>>> parse and instanciate very simple beans.
>>> See:
>>> =A0 https://svn.apache.org/repos/asf/geronimo/sandbox/gnodet/blueprint/=
org.apache.felix.blueprint/src/test/java/org/apache/felix/blueprint/WiringT=
est.java
>>> and the blueprint xml
>>> =A0 https://svn.apache.org/repos/asf/geronimo/sandbox/gnodet/blueprint/=
org.apache.felix.blueprint/src/test/resources/test-wiring.xml
>>
>> Since you're not using iPojo now there is no point of having two
>> separate efforts of implementing rfc124. So I think we should merge
>> into one project. For example, let's take your parser and integrate
>> with my (and Rick's) code and go from there. I already experimented
>> with xbean-reflect and I think it might work but will need some extra
>> modifications.
>>
>> Jarek
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>