cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tully, Gary" <Gary.Tu...@iona.com>
Subject RE: Architecture of cxf
Date Fri, 21 Sep 2007 12:20:41 GMT
Hi Dan,

Yes, the "2.1 migration guide" is very important.

Merging the utilities and rt-core modules with the api module makes
sense as they are all part of the api but there may be an argument for
keeping some separation between "must have" and "can have" api
functionality.
For example, to create and programmatically configure an endpoint you
"must have" cxf-api. To add your own interceptor that parses the payload
and needs access to the message schemas you "can have" cxf-dev-api that
will make your life easier.
 
dev-api can contain the common utilities and much of rt-core. Cxf-api
remains and possibly takes some packages from common-utilities.
Now the fact that the delineation is a bit loose maybe an argument for
just having one big api bundle but I think for first time users,
limiting the amount of api/capability that is exposed is liberating in
that it narrows the learning space. Cxf-dev-api on the other hand
emphasises the extensibility.

On api or impl, the issue comes into play from an OSGi perspective when
the interface/implementation is split across jars. Like the existing api
and rt modules. 
The OSGi advice is: an exported package should not span bundles (think
jars). This allows substutability at the package level and ensures that
inter-package dependencies will work, that is, that there will be a
shared classloader for the entire package. It is possible to workaround
this using fragments and wrapper bundles but in order to have a one to
one mapping between existing CXF module jars and OSGi bundles, a package
naming split using something like .impl is required to ensure package
isolation.

This will all fall apart from in an OSGi deployment scenario however it
there are large (or small) implementation level dependencies (rather
than api interface dependencies) between modules. From an Architecture
perspective there should not be. The good news is that OSGi framework
will simply not allow this to happen at runtime.

I guess the idealised view is that the cxf module jars can be useable as
they are in an OSGi environment by simply adding some manifests and
simple activators. Making the .impl split between compile/runtime,
interface/implementation is a good start in this direction. 
Working through the ramifications however will probably throw up areas
of the code that need some work to clear up their inter module
dependencies.

Gary.







> -----Original Message-----
> From: Daniel Kulp [mailto:dkulp@apache.org] 
> Sent: 20 September 2007 23:03
> To: cxf-user@incubator.apache.org
> Cc: Tully, Gary; Christian Schneider
> Subject: Re: Architecture of cxf
> 
> 
> Gary,
> 
> I've definitely thought about that.   The issue now is 
> compatibility.    
> If people are subclassing 
> org.apache.cxf.interceptor.BareInInterceptor, 
> and we move it, they have to update code.   I have no problem 
> with that, 
> we just need to start a section on the wiki for "2.1 migration guide" 
> information so we make sure it's all tracked.
> 
> First step is probably finding the packages that would be 
> affected so we can examine them.
> 
> The other issue that keeps popping up is  whether 
> cxf-common-utilities, 
> cxf-api, and cxf-rt-core SHOULD be merged into one.   IMO, 
> common-utilities and cxf-api really should be merged together as they 
> both really are the API's.   I could also see much of core 
> since a LOT 
> of the rest of the stuff depends on stuff there.   Thus, should they 
> be "api" and not "impl" things?    It's an interesting discussion.
> 
> 
> Dan
> 
> 
> On Thursday 20 September 2007, Tully, Gary wrote:
> > Hi Dan,
> > When looking at CXF from an OSGi bundle perspective the 
> duplication of 
> > packages between api and implementation limits the modularity. Both 
> > interface and implementation are available to dependants by default.
> >
> > Would we consider adding an .impl to the implementation 
> package names 
> > in CXF.
> >
> > org.apache.cxf.interceptor.Inerceptor
> > org.apache.cxf.interceptor.impl.BareInInterceptor
> >
> > This would help Message.properties also.
> >
> > Best Regards,
> > Gary.
> >
> > > -----Original Message-----
> > > From: Daniel Kulp [mailto:dkulp@apache.org]
> > > Sent: 20 September 2007 01:48
> > > To: cxf-user@incubator.apache.org
> > > Cc: Christian Schneider
> > > Subject: Re: Architecture of cxf
> > >
> > >
> > > We have a few places where package names exist in both the API jar
> > > as well as in the rt-* jars.   This may be causing some 
> issues with
> > > the analysis.  They CERTAINLY have caused issues with the 
> i18n stuff 
> > > as grabbing the Message.properties seems to grab 
> whichever is in the
> > > classpath first.   Definitely something I'd like to see 
> cleaned up.
> > >
> > > Dan
> > >
> > > On Wednesday 19 September 2007, Christian Schneider wrote:
> > > > I have done a second try at displaying the architecture.
> > >
> > > This time I
> > >
> > > > only included the cxf-rt* jars in the model.
> > > > This looks much better already ;-) Any idea why inlcuding the 
> > > > other jars especially the api jar gave me so many cycles?
> > > >
> > > > This architecture view below shows only some cycles.
> > > >
> > > > Best regards
> > > >
> > > > Christian Schneider
> > >
> > > --
> > > J. Daniel Kulp
> > > Principal Engineer
> > > IONA
> > > P: 781-902-8727    C: 508-380-7194
> > > daniel.kulp@iona.com
> > > http://www.dankulp.com/blog
> >
> > ----------------------------
> > IONA Technologies PLC (registered in Ireland) Registered Number: 
> > 171387 Registered Address: The IONA Building, Shelbourne 
> Road, Dublin 
> > 4, Ireland
> 
> 
> 
> --
> J. Daniel Kulp
> Principal Engineer
> IONA
> P: 781-902-8727    C: 508-380-7194
> daniel.kulp@iona.com
> http://www.dankulp.com/blog
> 

----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Mime
View raw message