cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <>
Subject Re: OSGi bundles and split packages....
Date Tue, 06 Dec 2011 10:42:41 GMT

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)

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<>  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

Sergey Beryozkin

Talend Community Coders


View raw message