Re: [OSGi] Support for RFC 124?
On Wed, Apr 15, 2009 at 18:24, Kevan Miller wrote: > > On Apr 13, 2009, at 6:38 PM, Guillaume Nodet wrote: > > I've integrated the Activator / ConversionService from the other > branch and moved mine into > https://svn.apache.org/repos/asf/geronimo/sandbox/blueprint > > The package is still org.apache.felix.blueprint. We may want to > change that, though I would think Felix is a better place for this > project than Geronimo, but that's a different point ... > > This is all good stuff. > Personally, we seem to have a critical mass for an implementation in > Geronimo. May be debatable, but I don't see a problem creating OSGi EEG > implementations in Geronimo. If it was OSGi core, I'd agree that Felix would > be a natural home... > I'd suggest we continue developing here (changing the package name). We can > always reevaluate... At some point, should move out of sandbox... > --kevan Agreed, most of the people interested in developing this implementation are in geronimo. However, Felix TLP is not just about the OSGi Core implementation, but also contains a lots of implementations of different RFCs or other libraries related to OSGi but completely independant of the Felix runtime. There is a plan to rework the felix web site to advocate that much more. Anyway, I think for the blueprint impl, moving to Felix would be a good thing because people looking for OSGi related stuff will never look into Geronimo for such a thing. But I agree to change to package to org.apache.geronimo.blueprint for now, and we'll see later what should be done about that. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [OSGi] Support for RFC 124?
On Apr 13, 2009, at 6:38 PM, Guillaume Nodet wrote: I've integrated the Activator / ConversionService from the other branch and moved mine into https://svn.apache.org/repos/asf/geronimo/sandbox/blueprint The package is still org.apache.felix.blueprint. We may want to change that, though I would think Felix is a better place for this project than Geronimo, but that's a different point ... This is all good stuff. Personally, we seem to have a critical mass for an implementation in Geronimo. May be debatable, but I don't see a problem creating OSGi EEG implementations in Geronimo. If it was OSGi core, I'd agree that Felix would be a natural home... I'd suggest we continue developing here (changing the package name). We can always reevaluate... At some point, should move out of sandbox... --kevan
Re: [OSGi] Support for RFC 124?
Guillaume Nodet 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. Rick, have you seen such a need anywhere in the spec ? Yes, there is a need for this in the spec, with NamespaceHandlers. The current spec doesn't provide any helper classes for doing the parse() and decorate() calls on NamespaceHandler, so it's necessary to to write your own implementation classes for the reflection classes. This means the extender implementation will be receiving back different implementations of these classes after a call. Since we're likely to want to hang additional references and implement additional methods in the metadata implementations, a deep copy of modified metadata seemed like the simplest solution. While 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 wrote: On Mon, Apr 13, 2009 at 2:51 PM, Guillaume Nodet wrote: 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: https://svn.apache.org/repos/asf/geronimo/sandbox/gnodet/blueprint/org.apache.felix.blueprint/src/test/java/org/apache/felix/blueprint/WiringTest.java and the blueprint xml 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
Re: [OSGi] Support for RFC 124?
On Tue, Apr 14, 2009 at 00:06, Jarek Gawor wrote: > 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). AFAIK, we use the same api. > 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. Right, sounds good. I'd like to here from Rick though if there was a specific purpose for doing that. Btw, I will be offline most of the week, so feel free to refactor the code at will. > 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 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. Rick, have you seen such >> a need anywhere in the spec ? While 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 wrote: >>> On Mon, Apr 13, 2009 at 2:51 PM, Guillaume Nodet wrote: 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: https://svn.apache.org/repos/asf/geronimo/sandbox/gnodet/blueprint/org.apache.felix.blueprint/src/test/java/org/apache/felix/blueprint/WiringTest.java and the blueprint xml 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 >> > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [OSGi] Support for RFC 124?
I've integrated the Activator / ConversionService from the other branch and moved mine into https://svn.apache.org/repos/asf/geronimo/sandbox/blueprint The package is still org.apache.felix.blueprint. We may want to change that, though I would think Felix is a better place for this project than Geronimo, but that's a different point ... On Tue, Apr 14, 2009 at 00:06, Jarek Gawor wrote: > 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 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. Rick, have you seen such >> a need anywhere in the spec ? While 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 wrote: >>> On Mon, Apr 13, 2009 at 2:51 PM, Guillaume Nodet wrote: 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: https://svn.apache.org/repos/asf/geronimo/sandbox/gnodet/blueprint/org.apache.felix.blueprint/src/test/java/org/apache/felix/blueprint/WiringTest.java and the blueprint xml 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 >> > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [OSGi] Support for RFC 124?
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 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. Rick, have you seen such > a need anywhere in the spec ? While 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 wrote: >> On Mon, Apr 13, 2009 at 2:51 PM, Guillaume Nodet wrote: >>> 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: >>> >>> https://svn.apache.org/repos/asf/geronimo/sandbox/gnodet/blueprint/org.apache.felix.blueprint/src/test/java/org/apache/felix/blueprint/WiringTest.java >>> and the blueprint xml >>> >>> 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 >
Re: [OSGi] Support for RFC 124?
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. Rick, have you seen such a need anywhere in the spec ? While 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 wrote: > On Mon, Apr 13, 2009 at 2:51 PM, Guillaume Nodet wrote: >> 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: >> >> https://svn.apache.org/repos/asf/geronimo/sandbox/gnodet/blueprint/org.apache.felix.blueprint/src/test/java/org/apache/felix/blueprint/WiringTest.java >> and the blueprint xml >> >> 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
Re: [OSGi] Support for RFC 124?
On Mon, Apr 13, 2009 at 2:51 PM, Guillaume Nodet wrote: > 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: > > https://svn.apache.org/repos/asf/geronimo/sandbox/gnodet/blueprint/org.apache.felix.blueprint/src/test/java/org/apache/felix/blueprint/WiringTest.java > and the blueprint xml > > 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
Re: [OSGi] Support for RFC 124?
I agree. It may need a bit of fixing in xbean-reflect to cope with conversions or typed values, but xbean-reflect should be able to handle most of the graph creation, which is a really good thing. On Mon, Apr 13, 2009 at 21:05, Rick McGuire wrote: > Guillaume Nodet wrote: >> >> 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. >> > > Based on what I've seen so far, it shouldn't be difficult to create Recipes > that perform all of the different flavors of injection/instantiation that > the blueprint service requires. > > Rick > >> See: >> >> https://svn.apache.org/repos/asf/geronimo/sandbox/gnodet/blueprint/org.apache.felix.blueprint/src/test/java/org/apache/felix/blueprint/WiringTest.java >> and the blueprint xml >> >> https://svn.apache.org/repos/asf/geronimo/sandbox/gnodet/blueprint/org.apache.felix.blueprint/src/test/resources/test-wiring.xml >> >> >> On Mon, Apr 13, 2009 at 16:08, Guillaume Nodet wrote: >> >>> >>> I think using JDK 5 is good enough. We just need to make sure we >>> don't use too much jdk 5 specific features so that we can use >>> retrotranslator if needed. >>> >>> On Mon, Apr 13, 2009 at 15:12, Rick McGuire wrote: >>> Jarek Gawor wrote: > > Btw, I checked in under > https://svn.apache.org/repos/asf/geronimo/sandbox/gawor/rfc124 a tiny > bit of code that I was playing around with to better understand RFC > 124. I'll keep on working and experimenting with it but anyone is > welcome to join. I'm planning to add some of the RFC 124 API > definitions next in order see what it would take to implement these > API. > > Jarek > > Before I go too far in writing new stuff, I think we should clarify the JVM target for this. The Blueprint spec outlines a couple of optional features for for implementations that run on Java5 and above that use generics. The bulk of the features will run fine on a 1.4.2 JVM version. Are we agreed that the target for this is a full implementation (which will require a Java 5 JVM to execute)? The answer to this determines whether generics can be used in the internal code as well. Rick >>> >>> -- >>> Cheers, >>> Guillaume Nodet >>> >>> Blog: http://gnodet.blogspot.com/ >>> >>> Open Source SOA >>> http://fusesource.com >>> >>> >> >> >> >> > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [OSGi] Support for RFC 124?
Guillaume Nodet wrote: 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. Based on what I've seen so far, it shouldn't be difficult to create Recipes that perform all of the different flavors of injection/instantiation that the blueprint service requires. Rick See: https://svn.apache.org/repos/asf/geronimo/sandbox/gnodet/blueprint/org.apache.felix.blueprint/src/test/java/org/apache/felix/blueprint/WiringTest.java and the blueprint xml https://svn.apache.org/repos/asf/geronimo/sandbox/gnodet/blueprint/org.apache.felix.blueprint/src/test/resources/test-wiring.xml On Mon, Apr 13, 2009 at 16:08, Guillaume Nodet wrote: I think using JDK 5 is good enough. We just need to make sure we don't use too much jdk 5 specific features so that we can use retrotranslator if needed. On Mon, Apr 13, 2009 at 15:12, Rick McGuire wrote: Jarek Gawor wrote: Btw, I checked in under https://svn.apache.org/repos/asf/geronimo/sandbox/gawor/rfc124 a tiny bit of code that I was playing around with to better understand RFC 124. I'll keep on working and experimenting with it but anyone is welcome to join. I'm planning to add some of the RFC 124 API definitions next in order see what it would take to implement these API. Jarek Before I go too far in writing new stuff, I think we should clarify the JVM target for this. The Blueprint spec outlines a couple of optional features for for implementations that run on Java5 and above that use generics. The bulk of the features will run fine on a 1.4.2 JVM version. Are we agreed that the target for this is a full implementation (which will require a Java 5 JVM to execute)? The answer to this determines whether generics can be used in the internal code as well. Rick -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [OSGi] Support for RFC 124?
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: https://svn.apache.org/repos/asf/geronimo/sandbox/gnodet/blueprint/org.apache.felix.blueprint/src/test/java/org/apache/felix/blueprint/WiringTest.java and the blueprint xml https://svn.apache.org/repos/asf/geronimo/sandbox/gnodet/blueprint/org.apache.felix.blueprint/src/test/resources/test-wiring.xml On Mon, Apr 13, 2009 at 16:08, Guillaume Nodet wrote: > I think using JDK 5 is good enough. We just need to make sure we > don't use too much jdk 5 specific features so that we can use > retrotranslator if needed. > > On Mon, Apr 13, 2009 at 15:12, Rick McGuire wrote: >> Jarek Gawor wrote: >>> >>> Btw, I checked in under >>> https://svn.apache.org/repos/asf/geronimo/sandbox/gawor/rfc124 a tiny >>> bit of code that I was playing around with to better understand RFC >>> 124. I'll keep on working and experimenting with it but anyone is >>> welcome to join. I'm planning to add some of the RFC 124 API >>> definitions next in order see what it would take to implement these >>> API. >>> >>> Jarek >>> >> >> Before I go too far in writing new stuff, I think we should clarify the JVM >> target for this. The Blueprint spec outlines a couple of optional features >> for for implementations that run on Java5 and above that use generics. The >> bulk of the features will run fine on a 1.4.2 JVM version. Are we agreed >> that the target for this is a full implementation (which will require a Java >> 5 JVM to execute)? The answer to this determines whether generics can be >> used in the internal code as well. >> >> Rick >> > > > > -- > Cheers, > Guillaume Nodet > > Blog: http://gnodet.blogspot.com/ > > Open Source SOA > http://fusesource.com > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [OSGi] Support for RFC 124?
I think using JDK 5 is good enough. We just need to make sure we don't use too much jdk 5 specific features so that we can use retrotranslator if needed. On Mon, Apr 13, 2009 at 15:12, Rick McGuire wrote: > Jarek Gawor wrote: >> >> Btw, I checked in under >> https://svn.apache.org/repos/asf/geronimo/sandbox/gawor/rfc124 a tiny >> bit of code that I was playing around with to better understand RFC >> 124. I'll keep on working and experimenting with it but anyone is >> welcome to join. I'm planning to add some of the RFC 124 API >> definitions next in order see what it would take to implement these >> API. >> >> Jarek >> > > Before I go too far in writing new stuff, I think we should clarify the JVM > target for this. The Blueprint spec outlines a couple of optional features > for for implementations that run on Java5 and above that use generics. The > bulk of the features will run fine on a 1.4.2 JVM version. Are we agreed > that the target for this is a full implementation (which will require a Java > 5 JVM to execute)? The answer to this determines whether generics can be > used in the internal code as well. > > Rick > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [OSGi] Support for RFC 124?
Jarek Gawor wrote: Btw, I checked in under https://svn.apache.org/repos/asf/geronimo/sandbox/gawor/rfc124 a tiny bit of code that I was playing around with to better understand RFC 124. I'll keep on working and experimenting with it but anyone is welcome to join. I'm planning to add some of the RFC 124 API definitions next in order see what it would take to implement these API. Jarek Before I go too far in writing new stuff, I think we should clarify the JVM target for this. The Blueprint spec outlines a couple of optional features for for implementations that run on Java5 and above that use generics. The bulk of the features will run fine on a 1.4.2 JVM version. Are we agreed that the target for this is a full implementation (which will require a Java 5 JVM to execute)? The answer to this determines whether generics can be used in the internal code as well. Rick
Re: [OSGi] Support for RFC 124?
I forgot one thing about JAXB which is the fact that after parsing the XML into jaxb pojos, we still need to transform those into the Blueprint metadata pojos ... On Friday, April 10, 2009, Guillaume Nodet wrote: > I've added my own work in progress at the following location: > https://svn.apache.org/repos/asf/geronimo/sandbox/gnodet/blueprint > > I'm not sure about the use of JAXB: > * first, it brings an unnecessary dependency on JDK 1.6 or jaxb impl + JDK > 5. > * second, I'm not sure if we would be able to handle custom > namespaces because they require passing the current element as a DOM > node, which means serializing the element back from pojos to a dom > node ... it does not sound really efficient > > Another thing is that I was thinking it might be possible at some > point to build an intermediary serialized format of the parsed > metadata at build time to avoid the cost of jaxb marshalling / xml > parsing when possible. I don't recall if there is a way to customize > the jaxb generated pojos, but having them being serializable might be > a good idea... > > On Fri, Apr 10, 2009 at 13:42, Rick McGuire wrote: >> Jarek Gawor wrote: >>> >>> Btw, I checked in under >>> https://svn.apache.org/repos/asf/geronimo/sandbox/gawor/rfc124 a tiny >>> bit of code that I was playing around with to better understand RFC >>> 124. I'll keep on working and experimenting with it but anyone is >>> welcome to join. I'm planning to add some of the RFC 124 API >>> definitions next in order see what it would take to implement these >>> API. >>> >> >> I just added some concrete implementations of the reflect APIs to the tree. >> >>> Jarek >>> >>> >> >> > > > > -- > Cheers, > Guillaume Nodet > > Blog: http://gnodet.blogspot.com/ > > Open Source SOA > http://fusesource.com > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [OSGi] Support for RFC 124?
I've added my own work in progress at the following location: https://svn.apache.org/repos/asf/geronimo/sandbox/gnodet/blueprint I'm not sure about the use of JAXB: * first, it brings an unnecessary dependency on JDK 1.6 or jaxb impl + JDK 5. * second, I'm not sure if we would be able to handle custom namespaces because they require passing the current element as a DOM node, which means serializing the element back from pojos to a dom node ... it does not sound really efficient Another thing is that I was thinking it might be possible at some point to build an intermediary serialized format of the parsed metadata at build time to avoid the cost of jaxb marshalling / xml parsing when possible. I don't recall if there is a way to customize the jaxb generated pojos, but having them being serializable might be a good idea... On Fri, Apr 10, 2009 at 13:42, Rick McGuire wrote: > Jarek Gawor wrote: >> >> Btw, I checked in under >> https://svn.apache.org/repos/asf/geronimo/sandbox/gawor/rfc124 a tiny >> bit of code that I was playing around with to better understand RFC >> 124. I'll keep on working and experimenting with it but anyone is >> welcome to join. I'm planning to add some of the RFC 124 API >> definitions next in order see what it would take to implement these >> API. >> > > I just added some concrete implementations of the reflect APIs to the tree. > >> Jarek >> >> > > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [OSGi] Support for RFC 124?
Jarek Gawor wrote: Btw, I checked in under https://svn.apache.org/repos/asf/geronimo/sandbox/gawor/rfc124 a tiny bit of code that I was playing around with to better understand RFC 124. I'll keep on working and experimenting with it but anyone is welcome to join. I'm planning to add some of the RFC 124 API definitions next in order see what it would take to implement these API. I just added some concrete implementations of the reflect APIs to the tree. Jarek
Re: [OSGi] Support for RFC 124?
I have started some stuff related to that too. The plan was to see if it's possible to implement RFC 124 on top of Felix iPojo. I have the apis, schemas and some of the parsing working ... If anyone is interested, we could maybe set up a lab for that. On Wed, Apr 8, 2009 at 19:23, Jarek Gawor wrote: > Btw, I checked in under > https://svn.apache.org/repos/asf/geronimo/sandbox/gawor/rfc124 a tiny > bit of code that I was playing around with to better understand RFC > 124. I'll keep on working and experimenting with it but anyone is > welcome to join. I'm planning to add some of the RFC 124 API > definitions next in order see what it would take to implement these > API. > > Jarek > > On Wed, Apr 1, 2009 at 6:47 AM, Rick McGuire wrote: >> Davanum Srinivas wrote: >>> >>> Folks, >>> >>> Any interest in support for RFC 124, "A Component Model for OSGi"? >>> http://www.osgi.org/download/osgi-4.2-early-draft.pdf >>> >>> This is in addition to typical J2EE artifacts that we already support. >>> >>> thanks, >>> dims >>> >>> >> >> Time, I think, to give this thread a kick. >> There are lots of different aspects to this, so I think we should first make >> an attempt at deciding what the target goal is here. RFC 124 (aka, the >> "blueprint service") is inherently an OSGi thing, so first we need to >> address what it means to add OSGi to Geronimo. And, I think, in general, >> this really means "OSGi as a Geronimo application programming model". >> >> This can have multiple meanings. One approach, already under discussion in >> the "Whence Geronimo kernel?" thread would be rearchitect the Geronimo >> kernel around OSGi bundles and the OSGi classloading model. In this mode, >> an application model should be fairly simple to add, though there may be >> some issues of bridging between the OSGi "bundle world" and the JEE >> programming model. Additions like the blueprint service might be directly >> usable within the Geronimo kernel for assembly and injection. >> Another approach would be to add an OSGi application container to Geronimo. >> This would allow OSGi/blueprint-based applications to be hosted on >> Geronimo, and there may be some Geronimo services that get exposed to the >> apps, but the apps run in their own separate environment. >> The container approach is, I believe, probably the easier path, but we I >> think we lose a lot of the advantages of the OSGi model in other places. >> Also, OSGi is working on a number of additional RFCs that will add >> different JEE concepts to the platform. I'd hate to think that Geronimo >> might need to maintain two versions of each of these pieces, one for the >> OSGi container and one for the non-OSGi world. >> Anyway, I think regardless of the implementation approach, we need to start >> discussing this in terms of "what does it mean to host an OSGi application >> on Geronimo?". Here are a few questions that immediately come to mind: >> >> 1. How are applications deployed? Is there some higher-level deployment >> model than the bundle level? >> 2. What services are available Geronimo application environment? Blueprint >> is certainly one service, what others do we need? >> 3. How is the config-admin service managed? Do we need Geronimo console >> access and editting of config admin properties? >> 4. Are there any bridges from the OSGi world to the JEE world? For >> example, is is possible to export service registry instances to JNDI? >> >> I think this is a good starting point for discussing ideasI'm sure there >> are additional questions that will come up in the discussions. >> >> Rick >> >> >> >> > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [OSGi] Support for RFC 124?
Btw, I checked in under https://svn.apache.org/repos/asf/geronimo/sandbox/gawor/rfc124 a tiny bit of code that I was playing around with to better understand RFC 124. I'll keep on working and experimenting with it but anyone is welcome to join. I'm planning to add some of the RFC 124 API definitions next in order see what it would take to implement these API. Jarek On Wed, Apr 1, 2009 at 6:47 AM, Rick McGuire wrote: > Davanum Srinivas wrote: >> >> Folks, >> >> Any interest in support for RFC 124, "A Component Model for OSGi"? >> http://www.osgi.org/download/osgi-4.2-early-draft.pdf >> >> This is in addition to typical J2EE artifacts that we already support. >> >> thanks, >> dims >> >> > > Time, I think, to give this thread a kick. > There are lots of different aspects to this, so I think we should first make > an attempt at deciding what the target goal is here. RFC 124 (aka, the > "blueprint service") is inherently an OSGi thing, so first we need to > address what it means to add OSGi to Geronimo. And, I think, in general, > this really means "OSGi as a Geronimo application programming model". > > This can have multiple meanings. One approach, already under discussion in > the "Whence Geronimo kernel?" thread would be rearchitect the Geronimo > kernel around OSGi bundles and the OSGi classloading model. In this mode, > an application model should be fairly simple to add, though there may be > some issues of bridging between the OSGi "bundle world" and the JEE > programming model. Additions like the blueprint service might be directly > usable within the Geronimo kernel for assembly and injection. > Another approach would be to add an OSGi application container to Geronimo. > This would allow OSGi/blueprint-based applications to be hosted on > Geronimo, and there may be some Geronimo services that get exposed to the > apps, but the apps run in their own separate environment. > The container approach is, I believe, probably the easier path, but we I > think we lose a lot of the advantages of the OSGi model in other places. > Also, OSGi is working on a number of additional RFCs that will add > different JEE concepts to the platform. I'd hate to think that Geronimo > might need to maintain two versions of each of these pieces, one for the > OSGi container and one for the non-OSGi world. > Anyway, I think regardless of the implementation approach, we need to start > discussing this in terms of "what does it mean to host an OSGi application > on Geronimo?". Here are a few questions that immediately come to mind: > > 1. How are applications deployed? Is there some higher-level deployment > model than the bundle level? > 2. What services are available Geronimo application environment? Blueprint > is certainly one service, what others do we need? > 3. How is the config-admin service managed? Do we need Geronimo console > access and editting of config admin properties? > 4. Are there any bridges from the OSGi world to the JEE world? For > example, is is possible to export service registry instances to JNDI? > > I think this is a good starting point for discussing ideasI'm sure there > are additional questions that will come up in the discussions. > > Rick > > > >
Re: [OSGi] Support for RFC 124?
Davanum Srinivas wrote: Folks, Any interest in support for RFC 124, "A Component Model for OSGi"? http://www.osgi.org/download/osgi-4.2-early-draft.pdf This is in addition to typical J2EE artifacts that we already support. thanks, dims Time, I think, to give this thread a kick. There are lots of different aspects to this, so I think we should first make an attempt at deciding what the target goal is here. RFC 124 (aka, the "blueprint service") is inherently an OSGi thing, so first we need to address what it means to add OSGi to Geronimo. And, I think, in general, this really means "OSGi as a Geronimo application programming model". This can have multiple meanings. One approach, already under discussion in the "Whence Geronimo kernel?" thread would be rearchitect the Geronimo kernel around OSGi bundles and the OSGi classloading model. In this mode, an application model should be fairly simple to add, though there may be some issues of bridging between the OSGi "bundle world" and the JEE programming model. Additions like the blueprint service might be directly usable within the Geronimo kernel for assembly and injection. Another approach would be to add an OSGi application container to Geronimo. This would allow OSGi/blueprint-based applications to be hosted on Geronimo, and there may be some Geronimo services that get exposed to the apps, but the apps run in their own separate environment. The container approach is, I believe, probably the easier path, but we I think we lose a lot of the advantages of the OSGi model in other places. Also, OSGi is working on a number of additional RFCs that will add different JEE concepts to the platform. I'd hate to think that Geronimo might need to maintain two versions of each of these pieces, one for the OSGi container and one for the non-OSGi world. Anyway, I think regardless of the implementation approach, we need to start discussing this in terms of "what does it mean to host an OSGi application on Geronimo?". Here are a few questions that immediately come to mind: 1. How are applications deployed? Is there some higher-level deployment model than the bundle level? 2. What services are available Geronimo application environment? Blueprint is certainly one service, what others do we need? 3. How is the config-admin service managed? Do we need Geronimo console access and editting of config admin properties? 4. Are there any bridges from the OSGi world to the JEE world? For example, is is possible to export service registry instances to JNDI? I think this is a good starting point for discussing ideasI'm sure there are additional questions that will come up in the discussions. Rick
Re: [OSGi] Support for RFC 124?
+1000 :-) Rex. 2009/3/17 Rick McGuire > It has been reworked much more that just the schema changes in the > standardization process. A lot of the service dynamics have changed, there > have been some fairly signification changes to type conversions and property > injection, a brand-new metadata API, new namespace handler support, etc. > Springsource hasn't even implemented some of the new features yet, so this > was far from a rubber-stamp effort. > > Rick > > Guillaume Nodet wrote: > >> RFC 124 is simply a ruberstamp around what Spring-DM provides. The only >> real difference afaik are a few changes in the schema (mostly the namespace >> and replacing "bean" by "component". >> This does not remove the usefulness of it btw... >> >> 2009/3/17 Davanum Srinivas mailto:dava...@gmail.com>> >> >>Folks, >> >>Any interest in support for RFC 124, "A Component Model for OSGi"? >>http://www.osgi.org/download/osgi-4.2-early-draft.pdf >> >>This is in addition to typical J2EE artifacts that we already support. >> >>thanks, >>dims >> >>-- >>Davanum Srinivas :: http://davanum.wordpress.com >> >> >> >> >> -- >> Cheers, >> Guillaume Nodet >> >> Blog: http://gnodet.blogspot.com/ >> >> Open Source SOA >> http://fusesource.com >> >> >> >
Re: [OSGi] Support for RFC 124?
Ok, my bad. I haven't followed closely the recent changes. The changes to the service dynamics look quite good actually. Thx for the info. 2009/3/17 Rick McGuire > It has been reworked much more that just the schema changes in the > standardization process. A lot of the service dynamics have changed, there > have been some fairly signification changes to type conversions and property > injection, a brand-new metadata API, new namespace handler support, etc. > Springsource hasn't even implemented some of the new features yet, so this > was far from a rubber-stamp effort. > > Rick > > Guillaume Nodet wrote: > >> RFC 124 is simply a ruberstamp around what Spring-DM provides. The only >> real difference afaik are a few changes in the schema (mostly the namespace >> and replacing "bean" by "component". >> This does not remove the usefulness of it btw... >> >> 2009/3/17 Davanum Srinivas mailto:dava...@gmail.com>> >> >>Folks, >> >>Any interest in support for RFC 124, "A Component Model for OSGi"? >>http://www.osgi.org/download/osgi-4.2-early-draft.pdf >> >>This is in addition to typical J2EE artifacts that we already support. >> >>thanks, >>dims >> >>-- >>Davanum Srinivas :: http://davanum.wordpress.com >> >> >> >> >> -- >> Cheers, >> Guillaume Nodet >> >> Blog: http://gnodet.blogspot.com/ >> >> Open Source SOA >> http://fusesource.com >> >> >> > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [OSGi] Support for RFC 124?
It has been reworked much more that just the schema changes in the standardization process. A lot of the service dynamics have changed, there have been some fairly signification changes to type conversions and property injection, a brand-new metadata API, new namespace handler support, etc. Springsource hasn't even implemented some of the new features yet, so this was far from a rubber-stamp effort. Rick Guillaume Nodet wrote: RFC 124 is simply a ruberstamp around what Spring-DM provides. The only real difference afaik are a few changes in the schema (mostly the namespace and replacing "bean" by "component". This does not remove the usefulness of it btw... 2009/3/17 Davanum Srinivas mailto:dava...@gmail.com>> Folks, Any interest in support for RFC 124, "A Component Model for OSGi"? http://www.osgi.org/download/osgi-4.2-early-draft.pdf This is in addition to typical J2EE artifacts that we already support. thanks, dims -- Davanum Srinivas :: http://davanum.wordpress.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [OSGi] Support for RFC 124?
RFC 124 is simply a ruberstamp around what Spring-DM provides. The only real difference afaik are a few changes in the schema (mostly the namespace and replacing "bean" by "component". This does not remove the usefulness of it btw... 2009/3/17 Davanum Srinivas > Folks, > > Any interest in support for RFC 124, "A Component Model for OSGi"? > http://www.osgi.org/download/osgi-4.2-early-draft.pdf > > This is in addition to typical J2EE artifacts that we already support. > > thanks, > dims > > -- > Davanum Srinivas :: http://davanum.wordpress.com > -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [OSGi] Support for RFC 124?
On Mar 17, 2009, at 8:58 AM, Davanum Srinivas wrote: Folks, Any interest in support for RFC 124, "A Component Model for OSGi"? http://www.osgi.org/download/osgi-4.2-early-draft.pdf This is in addition to typical J2EE artifacts that we already support. Yes. You'll find discussion about this in the "Whence the geronimo kernel?" thread... --kevan
Re: [OSGi] Support for RFC 124?
Davanum Srinivas wrote: Folks, Any interest in support for RFC 124, "A Component Model for OSGi"? http://www.osgi.org/download/osgi-4.2-early-draft.pdf This is in addition to typical J2EE artifacts that we already support. thanks, dims I think this would be a very cool thing to support. I think first we'd have to address the issue of first providing an OSGi framework environment hosted by Geronimo. Once you've done that, RFC 124, is a natural to add on top of that. Once you have that, defined, then you can start playing with things like accessing OSGi-based services from JEE components, which would be a really powerful next step. Rick PS, in the interests of full disclosure, I should note that I'm currently working on the compliance tests suite for RFC 124, so I've had a bit of experience at seeing this in action.
[OSGi] Support for RFC 124?
Folks, Any interest in support for RFC 124, "A Component Model for OSGi"? http://www.osgi.org/download/osgi-4.2-early-draft.pdf This is in addition to typical J2EE artifacts that we already support. thanks, dims -- Davanum Srinivas :: http://davanum.wordpress.com
