deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lincoln Baxter, III" <lincolnbax...@gmail.com>
Subject Re: CDI XML Config
Date Thu, 17 Jan 2013 18:01:56 GMT
Yes, basically native XML configuration of CDI in addition to custom
schemas and parsers for domain-specific configuration. Excellent.


On Thu, Jan 17, 2013 at 12:19 PM, Jason Porter <lightguard.jp@gmail.com>wrote:

> There have been some interesting developments with regards to the need of
> an XML configuration utility for CDI. Naturally we feel DeltaSpike is the
> correct location for this. I'll go into some of the history of CDI XML
> Configuration and other ideas that have come up within Red Hat and also the
> Fuse community, lastly we will propose an idea for the DeltaSpike project.
>
> === History
>
> The CDI specification (JSR 299 public draft) initially had the requirements
> of an XML configuration similar to what Spring has. This was later dropped
> in future versions of the specification in exchange for Portable
> Extensions. One of the first things Seam 3 completed back in 2009 was an
> implementation of the dropped XML configuration as a CDI extension,
> unfortunately it wasn't fully portable, but that's water under the bridge.
> Primarily this was used to configure and include archives that did not
> contain a beans.xml file and were not picked up by CDI.  There were also
> some uses later in Seam 3 that required the use of the XML configuration,
> namely early releases of Seam Security.
>
> To my knowledge it didn't see a lot of use besides Seam Security, unless
> people simply didn't talk about it. There were very few questions about it
> on the Seam forums outside of configuring Seam Security. The XML
> configuration was later moved into Solder as it was viewed as something
> core that many people could / would use. Fast forward a bit to DeltaSpike.
> It was originally discussed as an important part to add to DeltaSpike,
> however, it hasn't been added yet and various discussions have happened
> since about what is exactly needed. It was eventually discussed to port
> what was in Seam 3 and add in the ability to apply some CDI concepts, such
> as interceptors, to many classes at once by use of a regular expression in
> the XML configuration. Other discussions have happened outside of
> DeltaSpike seeking an XML configuration for CDI.
>
> === Discussions with Drools and Fuse
>
> The Drools developers would like to use CDI, but need the ability to allow
> users to configure things via XML similar to the Spring support that
> currently exists within Drools. Seam 3's XML Configuration was seen as a
> good means of achieving this, but with Seam 3 no longer in development and
> DeltaSpike lacking the XML Configuration this hasn't happened yet. It's
> still a desired feature.  Ideally the same configuration file could be used
> to configure both Spring and CDI, easing migration, and using something
> familiar to current users.
>
> The Fuse community currently integrates with Spring and OSGi using an XML
> configuration file. They're seeking a way to do a similar integration and
> configuration with CDI. The OSGi integration is done with OSGi Blueprint
> XML, which is very similar to Spring XML.
>
> === Proposed idea
>
> Looking at the existing implementation of the CDI Configuration (Seam XML
> Configuration) and the OSGi Blueprint schema, both align fairly well. It's
> not a 100% alignment, but they overlap in many areas. The Spring XML
> configuration also overlaps in areas. I propose we create an XML
> Configuration module in DeltaSpike that will make use of the standard CDI
> metadata classes to hold and configure Beans and AnnotatedTypes and add
> them to the CDI lifecycle.  This solution would also allow for a
> configurable and pluggable parser to map the various XML configurations to
> the CDI metadata. A user could create their parser and configure DeltaSpike
> to use it via standard DeltaSpike configuration. We propose that within the
> DeltaSpike project a native CDI parser (like what was proposed in the spec)
> and a Blueprint XML parser be available to users.
>
> --
> Jason Porter
> http://lightguard-jp.blogspot.com
> http://twitter.com/lightguardjp
>
> Software Engineer
> Open Source Advocate
>
> PGP key id: 926CCFF5
> PGP key available at: keyserver.net, pgp.mit.edu
>



-- 
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."

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