cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <sberyoz...@gmail.com>
Subject Re: OSGi bundles and split packages....
Date Tue, 06 Dec 2011 15:18:11 GMT
On 06/12/11 10:42, 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)
> 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

May be we should just continue on the OSGI-fication path instead of 
introducing two more big bundles...
I thought that adding those extra bundles can 'cover' most of what CXF 
users do with CXF in the short to medium term, but I'm getting a bit 
concerned if making a JAXRS dep non-optional for the cxf-bundle can 
affect somehow the existing SOAP-only cxf-bundle consumers. May be this 
concern is not founded but you never know :-)

Anyway, making major individual modules OSGI-friendly is a good/right 
idea on its own

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

Mime
View raw message