deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@redhat.com>
Subject Re: CDI XML Config Introductions
Date Fri, 18 Jan 2013 13:41:37 GMT

I've added last week a non-osgi mode for blueprint, so you have full blueprint support for
< 300k (not even the osgi api is needed).
I don't think there's any need to fork blueprint at this point and something like what has
been done for spring/cdi integration looks doable for blueprint/cdi integration as well.

The thing I'm not sure about yet is (if needed), the blueprint/cdi/osgi integration, the main
problem is being able to have the two osgi extenders cooperate together.  AFAIU the spring/cdi
integration is mostly controlled by CDI which creates the spring context.  That would work
in a non osgi environment, but might a bit more tricky in a real OSGI container.

I'm not sure what's the best place to develop such a blueprint/cdi integration, but in all
cases, I'd be happy to help if you need.

Guillaume

On 17 janv. 2013, at 19:00, "Lincoln Baxter, III" <lincolnbaxter@gmail.com> wrote:

> What do you think guys? Do we have enough now for someone to type up their requirements?
> 
> As a start, I think we are basically leaning toward using/forking Apache Blueprint directly
for use in CDI. Correct me if I am wrong.
> 
> 
> On Thu, Jan 17, 2013 at 12:13 PM, Charles Moulliard <ch007m@gmail.com> wrote:
> Hi Lincoln,
> 
> Did you have the time to prepare a more formal ermail ?
> 
> Regards,
> 
> Charles
> 
> 
> On Tue, Jan 15, 2013 at 7:51 PM, Lincoln Baxter, III <
> lincolnbaxter@gmail.com> wrote:
> 
> > Sorry. We'll put in a more formal and detailed email about this, instead of
> > this very vague forward. To be continued.
> >
> >
> > On Tue, Jan 15, 2013 at 1:32 PM, Lincoln Baxter, III <
> > lincolnbaxter@gmail.com> wrote:
> >
> > > Add deltaspike-dev.
> > >
> > >
> > > On Tue, Jan 15, 2013 at 1:30 PM, Pete Muir <pmuir@redhat.com> wrote:
> > >
> > >> Sounds good, do you want to draft up an email introducing the subject,
> > >> and send to this list for a quick review. IMO if we get a good initial
> > >> intro email written, then it will prevent the endless round of "yes
> > but" we
> > >> might get otherwise ;-)
> > >>
> > >>
> > >> On 15 Jan 2013, at 18:29, Jason Porter wrote:
> > >>
> > >> > Since we're looking at adding this to DeltaSpike, does anyone mind
if
> > >> we move this discussion over to the DeltaSpike mailing list? That way
> > >> everyone involved can add their feedback (and hopefully get things going
> > >> again).
> > >> >
> > >> > ----- Original Message -----
> > >> >> From: "James Strachan" <jstracha@redhat.com>
> > >> >> To: "Pete Muir" <pmuir@redhat.com>
> > >> >> Cc: "Lincoln Baxter, III" <lincolnbaxter@gmail.com>, "Mark
Proctor"
> > <
> > >> mproctor@redhat.com>, "Jason Porter"
> > >> >> <jporter@redhat.com>, "Brad Davis" <bdavis@redhat.com>,
"Brad
> > Davis" <
> > >> bradsdavis@gmail.com>, "Guillaume Nodet"
> > >> >> <gnodet@redhat.com>
> > >> >> Sent: Tuesday, January 15, 2013 11:06:12 AM
> > >> >> Subject: Re: CDI XML Config Introductions
> > >> >>
> > >> >> In addition to being an OSGi spec, supporting XML namespace
> > >> >> extensions (with Apache Camel support) and included in JBoss Fuse
/
> > >> >> Apache Karaf by default, it has an added advantage of having a
> > >> >> current implementation too (around 300Kb only depends on slf4j)
in
> > >> >> the apache aries project.
> > >> >>
> > https://github.com/apache/aries/tree/trunk/blueprint/blueprint-noosgi
> > >> >>
> > >> >> (the above module is the one Guillaume created to extract all
the
> > >> >> OSGi stuff from the regular blueprint implementation so its easier
> > >> >> to consume without any OSGi at all)
> > >> >>
> > >> >> the only bit missing is wiring/bridging the bean definitions into
the
> > >> >> CDI container. So maybe the blueprint-CDI thing could just be
an
> > >> >> extension to aries-blueprint?
> > >> >>
> > >> >>
> > >> >> Incidentally its also easy to include the OSGi stuff (so bundle
> > >> >> listeners, OSGi registry & config admin) by using the regular
aries
> > >> >> blueprint jar and just using pojosr
> > >> >> http://code.google.com/p/pojosr/
> > >> >>
> > >> >> which is a kinda 'static OSGi container' that reuses whatever
the
> > >> >> classpath the JVM/container has created but boots up an OSGi
> > >> >> container which can run blueprint & other osgi bundles. We
use this
> > >> >> in camel to run camel blueprint XML stuff - with osgi bundles
and
> > >> >> OSGi registry stuff - in a maven plugin.
> > >> >> http://camel.apache.org/camel-run-maven-goal.html
> > >> >>
> > >> >> Here's the maven module that includes blueprint + pojosr on the
flat
> > >> >> classpath if you're interested…
> > >> >>
> > >>
> > https://github.com/apache/camel/tree/trunk/components/camel-test-blueprint
> > >> >>
> > >> >>
> > >> >> On 15 Jan 2013, at 17:29, Pete Muir wrote:
> > >> >>
> > >> >>> Add James.
> > >> >>>
> > >> >>> Mark and I have discussed the same, except using blueprint,
which
> > >> >>> is a fork of spring beans anyway (and an open spec).
> > >> >>>
> > >> >>> On 15 Jan 2013, at 17:27, Lincoln Baxter, III wrote:
> > >> >>>
> > >> >>>> Brad and Mark want to discuss XML configuration in CDI.
I told
> > >> >>>> them that there was some progress here and that Jason,
you were
> > >> >>>> the one to talk to.
> > >> >>>>
> > >> >>>> Brad and I were discussing forking Spring Beans and porting
it to
> > >> >>>> CDI which I think is a very good strategic idea.
> > >> >>>>
> > >> >>>> I'll let him take it from here.
> > >> >>>>
> > >> >>>> --
> > >> >>>> Lincoln Baxter, III
> > >> >>>> http://ocpsoft.org
> > >> >>>> "Simpler is better."
> > >> >>>
> > >> >>
> > >> >>
> > >> >> James
> > >> >> -------
> > >> >> Red Hat
> > >> >>
> > >> >> Email: jstracha@redhat.com
> > >> >> Web: http://fusesource.com
> > >> >> Twitter: jstrachan, fusenews
> > >> >> Blog: http://macstrac.blogspot.com/
> > >> >>
> > >> >> Open Source Integration
> > >> >>
> > >> >>
> > >>
> > >>
> > >
> > >
> > > --
> > > Lincoln Baxter, III
> > > http://ocpsoft.org
> > > "Simpler is better."
> > >
> >
> >
> >
> > --
> > Lincoln Baxter, III
> > http://ocpsoft.org
> > "Simpler is better."
> >
> 
> 
> 
> --
> Charles Moulliard
> Apache Committer / Sr. Enterprise Architect (RedHat)
> Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com
> 
> 
> 
> -- 
> Lincoln Baxter, III
> http://ocpsoft.org
> "Simpler is better."


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message