Re[4]: Felix Util Bundle

[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: Hibernate, Transactions, OSGI...

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

[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

[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