Pull out CGLib and reexport in in OSGi

[gissuebot]

From kristoff.kiefer on July 06, 2009 12:31:06

Hi,

would it be possible to pull out the CGlib from where it is now (internal.*), put it in it's own
bundle and reexport the dependency from Guice?
At least making it a dependency and not swallowing it up?

As matters stand now for OSGi I need to break open many implementation details for my
interfaces due to that FastClass issue. (Cannot access Package-Private types)
This is quite ugly because it clutters my public interfaces. Importing a CGLib-Bundle to my code
doesn't help the issue either since the package names differ.

Could we have CGLib moved out of Guice and potentially reexported?

Thanks

Original issue: http://code.google.com/p/google-guice/issues/detail?id=400

[gissuebot]

From mcculls on October 30, 2009 21:23:56

My latest round of changes to the classloading/proxying code means that you'll only
need to make classes public or protected if you are using method-interception. This
should drastically cut down on the number of classes that you need to expose. I'm
also improving the error message to identify exactly which class is involved.

Often it's just the implementation class and its constructor that you need to make
protected or public, and only when running in strict containers like OSGi. Also if
you're using OSGi, you could keep these hidden in a non-exported package to avoid
leaking details.

BTW the reason CGLIB is internalized is because it's an implementation detail that we
don't want clients to rely on. Similarly it's repackaged to avoid clashes with other
versions of CGLIB on the classpath when running in standard Java containers.

So in summary: I very much doubt we'll be extracting CGLIB as a public dependency,
but the 2.1 release should allow you to keep classes package-private unless using
method-interception.

[gissuebot]

From sberlin on May 02, 2010 05:36:48

Stuart summarized the resolution very well in comment #1.

Status: WontFix