cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: OSGi bundles and split packages....
Date Tue, 06 Dec 2011 20:05:41 GMT
On Tuesday, December 06, 2011 10:42:41 AM Sergey Beryozkin wrote:
> Hi
> 
> On 05/12/11 19:37, Daniel Kulp wrote:
> > On Monday, December 05, 2011 7:21:59 PM David Bosschaert wrote:
> >> Big +1 from me on this (obviously). The fragment approach seems like a
> >> sensible idea to me as a migration strategy.
> > 
> > Another approach COULD be to create a "cxf-core" (not cxf-rt-core)
> > bundle that is a shade/bundle of the 3 (or 4 if we include jaxb).   
> > Plus's and minus's both ways.    I think LONG term, I'd like a single
> > cxf-core, but I think that it would be better to do that AFTER we kind
> > of go through all 3 jars and figure out what should really be in there
> > and what could be pulled out into separate bundles.   For example, all
> > the WSDL stuff in rt-core could likely be pulled into a specific
> > ws-core bundle or something that isn't needed by jaxrs. Some of the
> > interceptors are really ws specific.  Etc...   But moving all of THAT
> > stuff around would be very problematic.  Easily a 3.0 type thing.
> > 
> > The stuff I was trying to describe below can likely be done for a 2.6
> > type things as it's mostly compatible with small, targetted, relatively
> > document- able changes where required.
> 
> How many bundles are we thinking of ?
>
> rt-core(possibly with jaxb)

Just that one, but even likely NOT that one by having commons/api/rt-core/jaxb 
as fragment bundles.

Basically, those four would become one bundle when deployed to OSGi, but all 
the other jars we build would become individual bundles that could be deployed 
individually.   Thus, the big bundle jars would no longer be needed.

>From a karaf standpoint, the features.xml could then have a "cxf-core" feature 
which would be the above 4 jars (plus deps) and then we can have features for 
the major things people care about that would install the required little 
jars.   For example, a cxf-jaxws feature would include cxf-rt-frontend-jaxws, 
frontend-simple, bindings-soap, ws-addr, etc...    A "cxf-ws-security" would 
add the rt-ws-security  modules.    We could keep a "cxf" feature which would 
be the "install everything" option like we have now.


Dan



> jaxws
> ws-addr
> ws-sec
> ws-pol
> jaxrs
> 
> This is may not be the best way forward, but what about creating a few
> more 'big' bundles, ex, cxf-jaxws (simple jaxws) and cxf-ws (similar to
> cxf-all or cxf-minimal but without jaxrs) - so we'd have
> 
> cxf (with non-opt jaxrs deps)
> cxf-minimal (with non-opt jaxrs deps)
> cxf-ws (no jaxrs, but with jaxws + ws*)
> cxf-jaxws (jaxws-only)
> cxf-jaxrs (jaxrs-only)
> 
> May be we can do it and continue on the path of gradually creating
> OSGI-friendly individual modules for 2.6. and beyond
> 
> Cheers, Sergey
> 
> > One more area that may be super problematic is the /schemas directory.
> > Haven't had a chance to look at that yet, but a bunch of the jars expose
> > schemas from there and you obviously cannot have a bunch of bundles
> > exposing the same schemas dir like that.   That's another huge issue.
> > 
> >> WRT to changing packages, if you are really worried about backward
> >> compatibility but would like to refactor the split packages out you
> >> *could* consider renaming the package and creating a compatibility
> >> bundle or fragment that contains the 'old' split packages and
> >> delegates to the new ones. The users can slowly migrate. Non-migrated
> >> users would need the compat bundle. Migrated ones will not need it...
> >> It's not always practical, but it's an option to consider...
> > 
> > Doesn't really work for CXF, at least of the areas I looked at.   For
> > the most part, the stuff that needs to move are interfaces that the
> > impls' would need to implement.   Thus, without some complex weaving to
> > add the interfaces onto the impls at runtime, it would be a bit more
> > difficult.
> > 
> > Dan
> > 
> >> Cheers,
> >> 
> >> David
> >> 
> >> On 5 December 2011 17:40, Daniel Kulp<dkulp@apache.org>  wrote:
> >>> I kind of did a little audit this morning to try and figure out how
> >>> hard it will be to split the big bundle into little bundles to
> >>> allow for smaller OSGi footprints and such by just loading the
> >>> desired
> >>> functionality into OSGi instead of the entire big bundle (and all
> >>> it's
> >>> deps).
> >>> 
> >>> At this point, we have 25 packages that are split across multiple
> >>> jars.
> >>> 
> >>>    16 of the 25 are split between common-utilities, api, and
> >>>    rt-core.
> >>> 
> >>> At this point, I'd likely just say make those 3 fragments of each
> >>> other.   In the future, then figure out how to split that "big"
> >>> bundle
> >>> up a bit better.   Some of the 16 are "easy" (like cxf/phase) but
> >>> not
> >>> really worth spending time on if all of them cannot be resolved.
> >>> 
> >>> Of the remaining 9, 5 are easy to resolve, 2 are "medium", and 2 are
> >>> hard and would have a big impact.
> >>> 
> >>> 
> >>> Here is my analysis:
> >>> 
> >>> "Big 3" packages:
> >>> org/apache/cxf/binding  cxf-api cxf-rt-core
> >>> org/apache/cxf/buslifecycle  cxf-api cxf-rt-core
> >>> org/apache/cxf/clustering  cxf-api cxf-rt-core
> >>> org/apache/cxf/configuration  cxf-api cxf-common-utilities
> >>> cxf-rt-core
> >>> org/apache/cxf/configuration/spring  cxf-common-utilities
> >>> cxf-rt-core
> >>> org/apache/cxf/endpoint  cxf-api cxf-rt-core
> >>> org/apache/cxf/feature  cxf-api  cxf-rt-core
> >>> org/apache/cxf/headers  cxf-api cxf-rt-core
> >>> org/apache/cxf/interceptor  cxf-api cxf-rt-core
> >>> org/apache/cxf/io  cxf-api cxf-rt-core
> >>> org/apache/cxf/phase  cxf-api cxf-rt-core
> >>> org/apache/cxf/service  cxf-api cxf-rt-core
> >>> org/apache/cxf/service/invoker  cxf-api cxf-rt-core
> >>> org/apache/cxf/transport  cxf-api cxf-rt-core
> >>> org/apache/cxf/workqueue  cxf-api cxf-rt-core
> >>> org/apache/cxf/wsdl  cxf-api cxf-rt-core
> >>> 
> >>> 
> >>> Not easy:
> >>> org/apache/cxf/jaxb  cxf-common-utilities cxf-rt-databinding-jaxb
> >>> 
> >>>     Classes from both are used all over the place.   Big user
> >>>     impact.
> >>>     We COULD consider JAXB databinding a "core" thing and
> >>>     fragment it
> >>>     in since JAXB is pretty much required for any usage of CXF.
> >>> 
> >>> org/apache/cxf/service/factory  cxf-rt-core cxf-rt-frontend-simple
> >>> 
> >>>     Couple classes in rt-core used by JAX-RS and thus not really
> >>>     pushable>>> 
> >>> into frontend-simple without pulling more deps for JAX-RS.  
> >>> Changing
> >>> package name in either place would affect users. (changing package
> >>> for
> >>> classes in rt-core would affect a LOT less users though)
> >>> 
> >>> 
> >>> 
> >>> Medium:
> >>> org/apache/cxf/ws/policy  cxf-api cxf-rt-ws-policy
> >>> 
> >>>    Move impls and interceptors to private package.  May impact
> >>>    users if
> >>>    
> >>>       referencing the impls/interceptors directly.
> >>>    
> >>>    Push abstract and basic stuff up to cxf-api
> >>>    Couple other issues to resolve (like WSPolicyFeature requires
> >>>    Spring)>>> 
> >>> org/apache/cxf/ws/addressing  cxf-api cxf-rt-ws-addr
> >>> 
> >>>    Moving all the classes from api to ws-addr can be done.  Users
> >>>    would
> >>> 
> >>> need to depend on cxf-rt-ws-addr in addition to cxf-api if using the
> >>> classes. The main one is the AddressingProperties interface.  Some
> >>> internal CXF classes will need to be updated and fixed, but nothing
> >>> major.   The only "hard" one would be AbstractMultiplexDestination's
> >>> call into the AddressingProperties, but that's all of 2 lines of
> >>> code
> >>> and could likely be handled better by have ws-add save the "TO" EPR
> >>> on
> >>> the message/exchange directly.
> >>> 
> >>> Easy:
> >>> org/apache/cxf/frontend  cxf-rt-core cxf-rt-frontend-simple
> >>> 
> >>>     Move from rt-core to sub-module (not used elsewhere anyway):
> >>> org/apache/cxf/management  cxf-common-utilities cxf-rt-management
> >>> 
> >>>     Change package for generated type.  No impact to users.
> >>> 
> >>> org/apache/cxf/transport/http  cxf-rt-core cxf-rt-transports-http
> >>> 
> >>>     Impl in "core" moved to private package, utility class moved
> >>>     to
> >>> 
> >>> common
> >>> 
> >>>     Possible impact to users as the utility class would move.
> >>> 
> >>> org/apache/cxf/tools/common  cxf-api cxf-tools-common
> >>> 
> >>>     Move to tools-common and update refs or replace with
> >>>     constants
> >>> 
> >>> org/apache/cxf/tools/validator  cxf-api cxf-tools-validator
> >>> 
> >>>     Move to tools-validator and adjust dependencies and set
> >>>     optional
> >>> 
> >>> imports
> >>> 
> >>> 
> >>> Anyway, what are people's thoughts on the above?   Is it worth
> >>> pursing
> >>> more closely for 2.6?   Other than the JAXB one above that still
> >>> needs
> >>> a good solution, the impact isn't very large and could easily be
> >>> documented in the migration guides.
> >>> 
> >>> 
> >>> Dan
-- 
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

Mime
View raw message