You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Peter Kriens <Pe...@aQute.biz> on 2007/03/19 11:40:27 UTC
Re[2]: Felix Util Bundle
Do I have to list the dangers of util bundles in this forum?
It is easy to make a jar that drags in a lot of unwanted components.
It is always so painful to install a jar just to find out it needs the
util bundle that needs ...
Of course many of the problems are alleviated if the code is included
in the target JAR and not imported.
Kind regards,
Peter Kriens
RSH> Felix Meschberger wrote:
>> Hi all,
>>
>> Over the last few days, I started thinking about whether it would be
>> worth it to have some kind of Felix Util Bundle. This bundle would
>> take all sorts of utility classes, which may be used by different
>> bundles. In this sense this would be kind of a library bundle. The
>> reason for this is, that there is some functionality, which is used
>> over and over and which tends to be reimplemented repeatedly, for
>> example:
>>
>>
>> Logging
>>
>> Logging is defined in the LogService Specification, but it might not
>> always be around or only be registered after first use. The simple
>> workaround is to create a helper class, which uses the LogService if
>> available or write to stdout/stderr otherwise. The Felix Util bundle
>> could provide such a helper class to prevent reinventing the wheel or
>> copying source code over and over ...
>>
>>
>> Read-Only Case-Insensitive String-Key Dictionary
>>
>> Another common definition found all over the OSGi specs is the
>> Dictionary which has String keys, which are treated ignoring case and
>> in some situations are read-only (see Config Admin and Service
>> Compontents). The Felix Util bundle could provide such a Dictionary.
>>
>>
>> Requirement/Capability Abstractions
>>
>> Both the bundlerepository bundle and in the framework use
>> Requirement/Capability abstractions of the [Dynamic]Import-Package and
>> Export-Package headers. In a (currently internal) project I use the
>> same abstraction to build a Bundle Repository Server. In providing
>> these abstractions in the Felix Util bundle, the common functionality
>> may be reutilized.
>>
>>
>> I see two use cases for this Felix Util bundle: In the standard case
>> of using the Felix framework, the bundle would be placed on the class
>> path with the o.a.f.framework jar and the packages be defined as
>> framework system packages. If using a different OSGi framework such as
>> Equinox or Knopflerfish the Felix Util bundle may simply be deployed
>> as another bundle.
>>
>>
>> What do you think of such a util bundle ? If there is any interest I
>> could also provide some initial implementation.
RSH> This idea came up a while back on the Oscar mailing list too, but never
RSH> quite made it to fruition.
RSH> The three examples you give are reasonable and all exist in some fashion
RSH> in the framework already, so they could likely be refactored slightly to
RSH> make them stand-alone in cases where they are not.
RSH> The only one that is currently problematic is the capability/requirement
RSH> stuff since it is still undergoing changes in the framework. There could
RSH> also be some debate here as to whether this should be defined here or in
RSH> OBR itself.
RSH> Of course, with the maven-bundle-plugin, we can eliminate some worries
RSH> about placement of this stuff, since we can just suck it in where it is
RSH> needed to make various distributions for different purposes.
->> richard
--
Peter Kriens Tel +33467542167
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
Re: Hibernate, Transactions, OSGI...
Posted by Stuart McCulloch <st...@jayway.net>.
Hi Daniel,
This topic has recently come up on the Spring-OSGi mailing list
spring-osgi@googlegroups.com - the main issue is whether the
transaction context is properly preserved in the thread context.
( see Spring-OSGi group at http://groups.google.com/group/spring-osgi )
Another thing to look out for is whether your persistence code
uses proxies or aop / weaving, because of the different class
loading pattern.
There should be no 'remote / asynchronous' issues because
the OSGi application still runs inside a single JVM process.
Cheers, Stuart
On 21/03/07, Daniel Murley <dm...@xbiosystems.com> wrote:
> Hi All,
>
> I'm looking for information around Hibernate and Transaction Managers in
> OSGI environments. Has anyone tried this before, or know of any resources
> that may be helpful to look at? Anything regarding cross bundle
> transactions would also be very helpful.
>
> Cheers,
>
> Daniel
>
>
Hibernate, Transactions, OSGI...
Posted by Daniel Murley <dm...@xbiosystems.com>.
Hi All,
I'm looking for information around Hibernate and Transaction Managers in
OSGI environments. Has anyone tried this before, or know of any resources
that may be helpful to look at? Anything regarding cross bundle
transactions would also be very helpful.
Cheers,
Daniel
Re: Re[4]: Felix Util Bundle
Posted by Marcel Offermans <ma...@luminis.nl>.
On Mar 20, 2007, at 9:39 , Peter Kriens wrote:
> I am that interested in making an obfuscator but shrinking the bundle
> could be an interesting function. I already have all the information
> anyway. Obviously I can only throw away private packages, with OSGi
> you never know who will use the exported packages.
>
> I actually think that this will be a problem with a generic tool,
> throwing away exported packages.
Check out this paragraph in the ProGuard examples documentation:
http://proguard.sourceforge.net/manual/examples.html#library
That was specifically designed for processing libraries.
Greetings, Marcel
Re[4]: Felix Util Bundle
Posted by Peter Kriens <Pe...@aQute.biz>.
I am that interested in making an obfuscator but shrinking the bundle
could be an interesting function. I already have all the information
anyway. Obviously I can only throw away private packages, with OSGi
you never know who will use the exported packages.
I actually think that this will be a problem with a generic tool,
throwing away exported packages.
Kind regards,
Peter Kriens
MO> On Mar 20, 2007, at 7:54 , Felix Meschberger wrote:
>> On 3/19/07, Marcel Offermans <ma...@luminis.nl> wrote:
>>> Something that might be interesting here is to use Bnd together with
>>> one of the code obfuscators. Not to obfuscate anything, but to rip
>>> out all utility code that is not used. That way you can just inline
>>> the stuff you actually use.
>>>
>>> That could be a strategy to try with all utility bundles, not just
>>> this one. It might save you a lot of code in big libraries of which
>>> you use only a small portion.
>>
>> Interesting, indeed. Couldn't this be done by BND ? After all BND has
>> all the inter-class dependencies to handle this, or am I completely
>> wrong ?
MO> It could be done by BND, but I would not want Peter to start
MO> implementing his own obfuscator, so it's probably best to choose an
MO> existing obfuscator and feed it the information that BND has
MO> "discovered". I just took a brief look at ProGuard (http://
MO> proguard.sf.net/) and it can be configured to just "strip" code.
>> Of course this fails blatantly when classes are accessed through
>> reflection, but this would definitely be a different story...
MO> Good obfuscators can even spot some of the more common reflection use
MO> cases:
MO> - Class.forName(stringConstant) and
MO> - (castthatrevealstheclass)Class.forName(whatever).newInstance()
MO> But in general you are right, you should probably use some caution
MO> when using such a tool.
MO> Another path might be to not link such a step in the packaging
MO> process to BND at all, and just create a separate post-processing
MO> step for it. In that case, you would want to be able to feed ProGuard
MO> the bundle and have it figure out the manifest itself. That does not
MO> sound too hard. :)
MO> Greetings, Marcel
--
Peter Kriens Tel +33467542167
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
Re: Re[2]: Felix Util Bundle
Posted by Marcel Offermans <ma...@luminis.nl>.
On Mar 20, 2007, at 7:54 , Felix Meschberger wrote:
> On 3/19/07, Marcel Offermans <ma...@luminis.nl> wrote:
>> Something that might be interesting here is to use Bnd together with
>> one of the code obfuscators. Not to obfuscate anything, but to rip
>> out all utility code that is not used. That way you can just inline
>> the stuff you actually use.
>>
>> That could be a strategy to try with all utility bundles, not just
>> this one. It might save you a lot of code in big libraries of which
>> you use only a small portion.
>
> Interesting, indeed. Couldn't this be done by BND ? After all BND has
> all the inter-class dependencies to handle this, or am I completely
> wrong ?
It could be done by BND, but I would not want Peter to start
implementing his own obfuscator, so it's probably best to choose an
existing obfuscator and feed it the information that BND has
"discovered". I just took a brief look at ProGuard (http://
proguard.sf.net/) and it can be configured to just "strip" code.
> Of course this fails blatantly when classes are accessed through
> reflection, but this would definitely be a different story...
Good obfuscators can even spot some of the more common reflection use
cases:
- Class.forName(stringConstant) and
- (castthatrevealstheclass)Class.forName(whatever).newInstance()
But in general you are right, you should probably use some caution
when using such a tool.
Another path might be to not link such a step in the packaging
process to BND at all, and just create a separate post-processing
step for it. In that case, you would want to be able to feed ProGuard
the bundle and have it figure out the manifest itself. That does not
sound too hard. :)
Greetings, Marcel
Re: Re[2]: Felix Util Bundle
Posted by Felix Meschberger <Fe...@day.com>.
On 3/19/07, Marcel Offermans <ma...@luminis.nl> wrote:
> Something that might be interesting here is to use Bnd together with
> one of the code obfuscators. Not to obfuscate anything, but to rip
> out all utility code that is not used. That way you can just inline
> the stuff you actually use.
>
> That could be a strategy to try with all utility bundles, not just
> this one. It might save you a lot of code in big libraries of which
> you use only a small portion.
Interesting, indeed. Couldn't this be done by BND ? After all BND has
all the inter-class dependencies to handle this, or am I completely
wrong ?
Of course this fails blatantly when classes are accessed through
reflection, but this would definitely be a different story...
Regards
Felix
Re: Re[2]: Felix Util Bundle
Posted by Marcel Offermans <ma...@luminis.nl>.
On Mar 19, 2007, at 11:58 , Felix Meschberger wrote:
> On 3/19/07, Peter Kriens <Pe...@aqute.biz> wrote:
>
>> Of course many of the problems are alleviated if the code is
>> included in the target JAR and not imported.
>
> True. If we include the classes by using tools such as the great
> BND this is
> ok, still it might create duplicate class instances, which might or
> might
> not be a problem with respect to memory consumption and performance. I
> personally like to share as much as possible (but to create as minimal
> dependencies as possible, of course).
We should probably not call this code a "bundle" and leave it up to
the user to either wrap it in a bundle or just inline the needed code
(on the other hand, there's no harm done when we distribute it as a
utility bundle that exports its classes anyway).
Something that might be interesting here is to use Bnd together with
one of the code obfuscators. Not to obfuscate anything, but to rip
out all utility code that is not used. That way you can just inline
the stuff you actually use.
That could be a strategy to try with all utility bundles, not just
this one. It might save you a lot of code in big libraries of which
you use only a small portion.
Greetings, Marcel
Re: Re[2]: Felix Util Bundle
Posted by Felix Meschberger <Fe...@day.com>.
Hi,
On 3/19/07, Peter Kriens <Pe...@aqute.biz> wrote:
>
> Do I have to list the dangers of util bundles in this forum?
>
> It is easy to make a jar that drags in a lot of unwanted components.
> It is always so painful to install a jar just to find out it needs the
> util bundle that needs ...
Quite true. My idea of such a util bundle is to provide very low level
functionality and hence get a bundle with no - if possible - dependencies
except Core Java classes and OSGi classes.
And having depdencies is just another problem we are faced anyway when using
third party libraries: we always have to resolve dependencies. At least with
bundle manifests explicitly stating these dependencies and OBR supporting
the resolution of those, we have come a long way ... Just my 2 cents.
Of course many of the problems are alleviated if the code is included
> in the target JAR and not imported.
True. If we include the classes by using tools such as the great BND this is
ok, still it might create duplicate class instances, which might or might
not be a problem with respect to memory consumption and performance. I
personally like to share as much as possible (but to create as minimal
dependencies as possible, of course).
Regards
Felix