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<[email protected]> 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
