Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [orbit-dev] Updating to Guice 3.0.0.no_aop

> I'm wondering if it is likely there will ever be a "aop=true" version in
> Orbit?

Short answer:
I don't think so since Guice with AOP does not work in a signed environment.

Technical details:
The AOP version uses byte code generation to create proxy classes on the fly for some features of Guice (e.g. Method interception). Those classes are created in the same package as the original class to allow for interception of package private operations. Since the class loaded will ensure that all classes from the same package are signed with the same key, a security error is raised when those proxy classes should be loaded. Unfortunately it's not only the method interception feature of guice which leads to classes that are generated on the fly.
Since all Eclipse bundles are signed, it's pretty pointless to add an aop version to the orbit.

Regards,
Sebastian

On 06.03.2012, at 20:23, David M Williams wrote:

> 
> I guess off-topic, but why would someone choose aop vs. no_aop? I am sure
> part of the answer is "if you need to ask, you don't need to know" :) but,
> I'm wondering if it is likely there will ever be a "aop=true" version in
> Orbit?
> 
> Also off topic: was the CQ specific to the no_aop version? Sounds like
> "source the same, but bytes codes different" is a new area of "IP
> Clearance" that hopefully doesn't get complicated, nor common place.
> 
>> As long as P2 takes care that aopalliance packages are installed when
> needed, I'm fine.
> 
> I believe the rule is that if the "import package" does not give any
> matching attribute, both p2 and OSGi interpret that as "don't care" and
> would feel free to choose either (blank, aop=true, or aop-false), but if
> you specify aop=false on your import package, then p2 and OSGi must find a
> package that specifies aop=false. Test early, test often :)  It would
> actually be nice to have an "aop=true" version to test with .... maybe you
> could play with a locally built one, exported as deployable plugin from
> your IIDE with those values (once with nothing, and again with aop=true,
> perhaps changing description to match (I am not talking about "real code"
> here), add that as a "test repo" along with the eventual orbit repo and
> make sure some "test installs" pick up the versions as expected.  If it
> does all work as expected, you might open a bug or pass along the info to
> the Google Guice folks? Part of the side purpose Orbit is (sort of) to
> encourage the world to make OSGi bundles and make them better :) ... maybe
> this could turn into a good success story? :)
> 
> Thanks,
> 
> 
> 
> 
> From:	Marcel Bruch <bruch@xxxxxxxxxxxxxxxxxx>
> To:	Orbit Developer discussion <orbit-dev@xxxxxxxxxxx>,
> Date:	03/06/2012 01:51 PM
> Subject:	Re: [orbit-dev] Updating to Guice 3.0.0.no_aop
> Sent by:	orbit-dev-bounces@xxxxxxxxxxx
> 
> 
> 
> 
> On 06.03.2012, at 19:03, David M Williams wrote:
> 
>>> Waiting little longer for potential OSGI experts' comments then.
>> 
>> Ok, now after thinking about this, having "no_aop" in the qualifier is
>> wrong and unworkable ... speaking as an OSGi expert :)
> 
> :-)
> 
>> The key is that the "matching attributes" such as "vendor" in the
>> Export-Package directive are relatively arbitrary, so you could use
>> something like
>> 
>> Export-Package: com.google.inject; aop=false; version="1.3", ....
> 
> Sounds good to me. Guice comes with a large set of extension fragments. But
> as far as I know, none of them is actually distinguishing whether the base
> framework is +/- aop. So I think it would work.
> 
> 
>> You'd also want to document clearly in the the Bundle-Description: that
>> this was the "no-aop" version.
> 
> OK.
> 
>> If someone wanted to use "require-bundle" then I think they'd have to
>> simply "require" the exact version/qualifier that had the aop or no_aop
>> they desired (that is, not sure there is a similar concept for "require
>> bundle".
> 
> If no one complains... OK for me. As long as P2 takes care that aopalliance
> packages are installed when needed, I'm fine.
> 
>> So, I think that's the right approach. If anyone has other insights,
> that'd
>> be great.
>> 
>> Second issue: You (and they) say have both 1.5 and 1.6 as minimum EE
>> environments, but I do not think that is ever needed. A minimum of 1.5
>> includes 1.6 so specifying both is redundant (unless, I a missing
>> something?) It does not rule out 1.7, for example.
> 
> 
> I didn't touch it because I wanted to make only minimal changes.
> I'll remove 1.6.
> 
> 
> I'll trigger the build later after the current run finished.
> 
> 
>> From:		 Marcel Bruch <bruch@xxxxxxxxxxxxxxxxxx>
>> To:		 Orbit Developer discussion <orbit-dev@xxxxxxxxxxx>,
>> Date:		 03/06/2012 09:54 AM
>> Subject:		 Re: [orbit-dev] Updating to Guice 3.0.0.no_aop
>> Sent by:		 orbit-dev-bounces@xxxxxxxxxxx
>> 
>> 
>> 
>> 
>> On 06.03.2012, at 15:36, David M Williams wrote:
>> 
>>> 
>>>> 2. I renamed the Bundle-Version to 3.0.0.no_aop_qualifier to show
>>>> that this bundle is the no-aop variant of Guice. The name "3.0.
>>>> 0.no_aop" is used by the Guice team itself. Here, however, I wonder
>>>> whether a vendor attribute should be used if someone wants to use
>>>> the standard Guice with AOP. If no-one stands up, I'll stick to the
>>>> Guice-given defaults.
>>> 
>>> I do not object to using 'no_app' in the qualifier ... but, it does seem
>> a
>>> bit odd. Keep in mind, I've only briefly thought about this, and am not
>>> familiar with "Guice".
>>> 
>>>> The name "3.0.0.no_aop" is used by the Guice team itself.
>>> 
>>> Are you saying they use that in the _version_ of Guice? Or the _name_?
> In
>>> particular, do they produce an OSGi bundle and use that as the version?
>> If
>>> so, then I think that would mean "3.0.0.no_app_qualifier" would be ok.
>> 
>> It's _version_. The original manifest looks like this
>> 
>> Bundle-Name: guice
>> Bundle-RequiredExecutionEnvironment: J2SE-1.5,JavaSE-1.6
>> Bundle-Copyright: Copyright (C) 2006 Google Inc.
>> Bundle-Vendor: Google, Inc.
>> Bundle-Version: 3.0.0.no_aop
>> Bundle-SymbolicName: com.google.inject
>> [...]
>> 
>>> I've have to check all the OSGi manifest directives/properties, but
>> sounds
>>> like something like "vendor" is a little more appropriate (are there
>> other
>>> candidate "properties" that would be useful, or is "vendor" the only
>>> choice?).
>> 
>> Using vendor is suggested by
>> 
> http://wiki.eclipse.org/Bundle_Naming#Issue_3_:_Distinguishing_different_implementations
> 
>> 
>> vendor doesn't feel appropriate, I agree.
>> 
>> 
>>> What does "no AOP" mean, exactly? Does it happen to mean "whole
> packages"
>>> are missing, without *.aop.* packages? If so, I'm surprised anything is
>>> needed at all, and perhaps another bundle/fragment with "aop" in name
>> (id)
>>> would be more appropriate when aop is provided. I'm concerned about
>> putting
>>> part of the bundle's functional semantics in the _version_ "number".
>> 
>>> From http://code.google.com/p/google-guice/wiki/OptionalAOP:
>> 
>> = Building Guice without AOP =
>> Guice has an ant task that creates a modified copy of the Guice
>> source-tree. The copy uses the *munge* preprocessor to remove all
>> bytecode-dependent APIs. Use the following commands to build Guice
> without
>> AOP support:
>> [...]
>> 
>> So it's basically the same source but a different bytecode.
>> 
>>> So, I am not saying I know the right answer and feel free to do it how
>> you
>>> think best ... that is, I am not objecting to you doing it ... but ...
>>> thought I'd "stand up" to say I think you are right to ask for feedback.
>> If
>>> no OSGi experts speak up on this list, perhaps you could also ask on
>>> OSGi-dev list for advice?
>> 
>> Waiting little longer for potential OSGI experts' comments then.
>> Thanks for your thoughts on this.
>> 
>> Marcel
>> 
>> 
>>> Thanks,
>>> 
>>> 
>>> 
>>> 
>>> 
>>> From:		 		  Marcel Bruch <bruch@xxxxxxxxxxxxxxxxxx>
>>> To:		 		  Orbit Developer discussion
> <orbit-dev@xxxxxxxxxxx>,
>>> Date:		 		  03/06/2012 07:42 AM
>>> Subject:		 		  [orbit-dev] Updating to Guice 3.0.0.no_aop
>>> Sent by:		 		  orbit-dev-bounces@xxxxxxxxxxx
>>> 
>>> 
>>> 
>>> Hi,
>>> 
>>> I'm going to update Guice to 3.0.0 tonight (after the build is fixed).
>> I've
>>> made a few changes to the original manifest which I'd like to present
>>> before committing this to Orbit:
>>> 
>>> 1. I've added com.google.inject.internal;version="1.3";x-internal:=true,
>>> since this package is used by XText.
>>> 
>>> 2. I renamed the Bundle-Version to 3.0.0.no_aop_qualifier to show that
>> this
>>> bundle is the no-aop variant of Guice. The name "3.0.0.no_aop" is used
> by
>>> the Guice team itself. Here, however, I wonder whether a vendor
> attribute
>>> should be used if someone wants to use the standard Guice with AOP. If
>>> no-one stands up, I'll stick to the Guice-given defaults.
>>> 
>>> 3. I've added Eclipse-ExtensibleAPI: true to enable PDE to recognize and
>>> handle extension fragments properly. This was added 23.12.2011 to
>>> Guice.jar.
>>> See
>>> 
>> 
> http://code.google.com/p/google-guice/source/detail?r=abfe40d6bf6e3b1a3703869c85dae9a0315cb782
> 
>> 
>>> 
>>> 
>>> 
>>> The final manifest is given below. If there are any issues with it
>>> (especially with Xtext needs), let me know.
>>> 
>>> Best,
>>> Marcel
>>> 
>>> 
>>> Manifest-Version: 1.0
>>> Export-Package: com.google.inject;version="1.3",
>>> com.google.inject.binder;version="1.3",
>>> com.google.inject.internal;version="1.3";x-internal:=true,
>>> com.google.inject.matcher;version="1.3",
>>> com.google.inject.name;version="1.3",
>>> com.google.inject.spi;version="1.3",
>>> com.google.inject.util;version="1.3"
>>> Bundle-Name: Google Guice (no_aop)
>>> Bundle-RequiredExecutionEnvironment: J2SE-1.5,
>>> JavaSE-1.6
>>> Bundle-Copyright: Copyright (C) 2006 Google Inc.
>>> Bundle-Vendor: Eclipse Orbit
>>> Bundle-Version: 3.0.0.no_aop_qualifier
>>> Bundle-ManifestVersion: 2
>>> Bundle-Description: Guice is a lightweight dependency injection framew
>>> ork for Java 5 and above
>>> Bundle-License: http://www.apache.org/licenses/LICENSE-2.0.txt
>>> Bundle-DocURL: http://code.google.com/p/google-guice/
>>> Import-Package: javax.inject
>>> Bundle-SymbolicName: com.google.inject
>>> Eclipse-ExtensibleAPI: true
>>> 
>>> _______________________________________________
>>> orbit-dev mailing list
>>> orbit-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/orbit-dev
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> orbit-dev mailing list
>>> orbit-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/orbit-dev
>> 
>> Thanks,
>> Marcel
>> 
>> --
>> Eclipse Code Recommenders:
>> w www.eclipse.org/recommenders
>> tw www.twitter.com/marcelbruch
>> g+ www.gplus.to/marcelbruch
>> 
>> _______________________________________________
>> orbit-dev mailing list
>> orbit-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/orbit-dev
>> 
>> 
>> 
>> _______________________________________________
>> orbit-dev mailing list
>> orbit-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/orbit-dev
> 
> 
> _______________________________________________
> orbit-dev mailing list
> orbit-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/orbit-dev
> 
> 
> 
> _______________________________________________
> orbit-dev mailing list
> orbit-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/orbit-dev

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail


Back to the top