Re: [equinox-dev] [orbit-dev] [e4-dev] Resolver Problem with guava and 4 javax.annotation)
On Wednesday, 5 November 2014 at 11:34, Tom Schindl wrote: Hi, With Mars (whether this is a regression in the Equinox-Resolver) needs to be discussed but I'd really like us to start a discussion if we can get rid of the javax.annotation bundle itself. For the reference if I install e(fx)clipse tooling into Mars M3 I get: osgi diag 317 org.eclipse.fx.ide.css [317] Bundle was not resolved because of a uses contraint violation. org.osgi.service.resolver.ResolutionException: Uses constraint violation. Unable to resolve resource org.eclipse.fx.ide.css [osgi.identity; osgi.identity=org.eclipse.fx.ide.css; type=osgi.bundle; version:Version=1.1.0.201411050807; singleton:=true] because it is exposed to package 'javax.annotation' from resources org.eclipse.osgi [osgi.identity; osgi.identity=org.eclipse.osgi; type=osgi.bundle; version:Version=3.10.100.v20141020-1414; singleton:=true] and javax.annotation [osgi.identity; osgi.identity=javax.annotation; type=osgi.bundle; version:Version=1.2.0.v201401042248] via two dependency chains. Chain 1: org.eclipse.fx.ide.css [osgi.identity; osgi.identity=org.eclipse.fx.ide.css; type=osgi.bundle; version:Version=1.1.0.201411050807; singleton:=true] require: ((osgi.wiring.bundle=org.eclipse.osgi)(bundle-version=3.7.0)) | provide: osgi.wiring.bundle: [org.eclipse.osgi, system.bundle] org.eclipse.osgi [osgi.identity; osgi.identity=org.eclipse.osgi; type=osgi.bundle; version:Version=3.10.100.v20141020-1414; singleton:=true] Chain 2: org.eclipse.fx.ide.css [osgi.identity; osgi.identity=org.eclipse.fx.ide.css; type=osgi.bundle; version:Version=1.1.0.201411050807; singleton:=true] require: ((osgi.wiring.bundle=org.eclipse.xtext)(bundle-version=2.0.0)) | provide: osgi.wiring.bundle; bundle-version:Version=2.8.0.v201409300608; osgi.wiring.bundle=org.eclipse.xtext; singleton:=true com.google.guava [osgi.identity; osgi.identity=com.google.guava; type=osgi.bundle; version:Version=15.0.0.v201403281430] import: (osgi.wiring.package=javax.annotation) | export: osgi.wiring.package: javax.annotation javax.annotation [osgi.identity; osgi.identity=javax.annotation; type=osgi.bundle; version:Version=1.2.0.v201401042248] Eclipse 4 IDE and Eclipse 4 Application Platform already has Java6 as a prerequisit so technically we don't need javax.annotation because it is provided by the JRE. Does anything in E4 use @javax.annotation.Priority which was added in 1.2? If so then the bundle is still needed because Java6 only includes version 1.0 of the spec. The problem is that all client bundles who use the e4 DI container do versioned imports whereas e.g. external bundles like guava do a version less import, so if we'd modify our own bundles to use the JRE version they would all fail. Do we need a boarder forum like cross-platform? Tom On 15.06.14 06:55, David M Williams wrote: I don't know if this problem was solved ... or worked around but didn't want the issue to get lost, so I opened a bug in Orbit, https://bugs.eclipse.org/bugs/show_bug.cgi?id=437470 to make sure the issue isn't lost (thought not sure it's a true Orbit Bug ... seemed as good a place as any). Thanks, From: David M Williams/Raleigh/IBM@IBMUS To: E4 Project developer mailing list e4-...@eclipse.org (mailto:e4-...@eclipse.org), Cc: orbit-...@eclipse.org (mailto:orbit-...@eclipse.org), Equinox development mailing list equinox-dev@eclipse.org (mailto:equinox-dev@eclipse.org) Date: 06/11/2014 02:55 AM Subject: Re: [equinox-dev] [e4-dev] Resolver Problem with guava and e4 (javax.annotation) Sent by: equinox-dev-boun...@eclipse.org (mailto:equinox-dev-boun...@eclipse.org) I don't think so because from their point of view they are requireing JavaSE-1.6 and so they can wire to javax.annotation without packages. They could remove the javax.annotation import completely because they anyways require JavaSE-1.6 Well, not quite. javax.annotation 1.0.0 has a BREE of 1.5 (but is native to only 1.6, according to_https://bugs.eclipse.org/bugs/show_bug.cgi?id=422981#c5_ ) javax.annotation 1.1.0 has a BREE of 1.5 (but is native to only 1.7, according to '') javax.annotation 1.2.0 has a BREE of 1.6 (but is native to only 1.8, according to '' -- I think -- assuming it made it in, but I do not know for sure) The idea being that projects could use annotations, as the specs came out, even on an older VM, rather than have to wait for the JRE that first contained it. ___ equinox-dev mailing list equinox-dev@eclipse.org (mailto:equinox-dev@eclipse.org) https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ orbit-dev mailing
Re: [equinox-dev] Kepler breaks m2e on IBM JVM
I've tracked this down to a difference in URLClassLoader.getResources behaviour between Juno and Kepler, but only when running on the IBM JVM: https://bugs.eclipse.org/bugs/show_bug.cgi?id=408955#c21 Perhaps it's related to the change that went in recently to fix https://bugs.eclipse.org/bugs/show_bug.cgi?id=375783 ? On 28 May 2013, at 08:41, Fred Bricon wrote: Hi, it seems *something* broke m2e on the IBM JVM in Kepler. *All* the m2e versions I tested (1.2.0 - 1.4.0) fail to start when run in Kepler + IBM JVM (Java 7.0). The same m2e versions work fine with Juno + IBM JVM. The same m2e versions work fine with Kepler + Oracle JVM. This issue prevents RC releases of EPP distros containing m2e (Java, Java EE) [1]. Apparently the Guice Container doesn't load properly, but I have no idea why. Anyone platform/equinox savvy has any idea of what might have caused the regression? [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=408955 Regards, Fred Bricon -- Have you tried turning it off and on again - The IT Crowd ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Problem when running Equinox with Maven and OSP4J's Pax Construct when behind a proxy
2009/6/13 Alex Blewitt alex.blew...@gmail.com This is a PAX issue, rather than Equinox. Indeed, Eclipse doesn't actually host the bundles on ibiblio at all ... they're put up by volunteers. that's right - Samad, if you're still seeing the error send a note to gene...@lists.ops4j.org and someone will help -- Cheers, Stuart You might try a pax-update from the PAX scripts to see if there is any updates. It may be that the Equinox version you've specified is no longer available. I recall I used pax-construct to create my project which defaulted to a right version of Equinox. Perhaps after update you can create a new project with that and then cut'n'paste the Equinox dependency. Alex Sent from my (new) iPhone On 12 Jun 2009, at 16:09, Samad Lotia samad.lo...@pasteur.fr wrote: Hello, I am trying to use Equinox with Maven and Pax Construct. When I type mvn pax:run, it correctly downloads all the bundles. However, Maven gets stuck when attempting to download Equinox: - Equinox 3.4.2 (v20081215-1030) : downloading... After ten minutes or so, Pax times out, saying that it wasn't able to obtain the bundle. I get this message: Oops, these has been a problem! URL [mvn:org.eclipse/osgi/3.4.3.v20081215-1030] could not be resolved. I have environment variables set up correctly ($http_proxy, $HTTP_PROXY, $HTTPS_PROXY, $FTP_PROXY), and I have provided proxy settings in my ~/.m2/settings.xml file. Here's some information on my computer: Output from uname: Linux deleted 2.6.18-128.1.6.el5 #1 SMP Wed Apr 1 09:10:25 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux Java version: Java(TM) SE Runtime Environment (build 1.6.0_10-b33) Maven version: Apache Maven 2.1.0 (r755702; 2009-03-18 20:10:27+0100) How can I fix this? Thanks, Samad ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Equinox boot delegation problem
2009/4/13 Richard S. Hall he...@ungoverned.org This came up recently and we discussed it within CPEG. Felix is incorrect in interpreting sun.io.* as a match for sun.io.SomeClass. good to get a definitive answer, will the wildcard wording be improved in the 4.2 spec? In other words, sun.io.* matches sub-packages of sun.io, but not sun.ioitself. This will be corrected in a future version of Felix. so to match org.foo as well as it's sub-packages you should use org.foo,org.foo.*? (because if you use org.foo* then that could match against org.foobar as well...) - richard On 4/13/09 2:48 AM, raks81 wrote: I have a bundle that uses db2 driver to talk to the DB. This version of the driver seems to be using classes from sun.io package. So when I add org.osgi.framework.bootdelegation=sun.io.* equinox throws a NCDF error. But when I change it to org.osgi.framework.bootdelegation=sun.* it seems to pick the classes from sun.io just fine. I am using Equinox 3.4.1 (launching using pax runner 0.17.2). JRE 1.5. Felix seems to interpret org.osgi.framework.bootdelegation=sun.io.* just fine. Thanks in advance! Raks -- Cheers, Stuart ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Equinox boot delegation problem
2009/4/13 Richard S. Hall he...@ungoverned.org On 4/13/09 4:41 AM, Stuart McCulloch wrote: 2009/4/13 Richard S. Hall he...@ungoverned.org On 4/13/09 4:12 AM, Stuart McCulloch wrote: 2009/4/13 Richard S. Hall he...@ungoverned.org This came up recently and we discussed it within CPEG. Felix is incorrect in interpreting sun.io.* as a match for sun.io.SomeClass. good to get a definitive answer, will the wildcard wording be improved in the 4.2 spec? Not sure about that. In other words, sun.io.* matches sub-packages of sun.io, but not sun.ioitself. This will be corrected in a future version of Felix. so to match org.foo as well as it's sub-packages you should use org.foo,org.foo.*? (because if you use org.foo* then that could match against org.foobar as well...) Yes, but I think only trailing package-level wildcards are supported, e.g., org.foo.*, not org.foo*... ok, I think the 4.2 spec should really spell out what wildcards are supported and how they match should I open a bug to track this, or do you want to follow this up with CPEG? If you feel it is not clear in the spec, then definitely open a bug at OSGi or at least bring it up on osgi-dev. ok, done... https://www.osgi.org/bugzilla/show_bug.cgi?id=47 - richard I could be wrong. - richard -- Cheers, Stuart -- Cheers, Stuart ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Extension Registry outside Equinox?
2009/3/10 Michael Greifeneder mik...@gmx.net Hello, I try to find out if the Extension Registry (org.eclipse.equinox.registry) can be used outside Equinox? I like the concept and I would like to use it with a Swing application. However I have to convince my project partners that we are not forced to stick with Equinox, although I don't think we are going to use any other OSGI implementation. I created a simply test case with Apache Felix and installed org.eclipse.equinox.common_3.5.0.v20090119-1830.jar org.eclipse.equinox.registry_3.4.100.v20081024-1200.jar org.eclipse.equinox.supplement_1.2.0.v20090127-1630.jar org.eclipse.equinox.util_1.0.1.v20081205-1800.jar from 3.5M5 I get this message during start of the registry: Error: Could not parse XML contribution for org.eclipse.equinox.registry;singleton:=true//plugin.xml. Any contributed extensions and extension points will be ignored. Hi Michael, yes it is possible, but you need to install the SAXParserFactory as a service before starting the registry bundle - I don't know if there's a small bundle in Equinox that will do this for you, but otherwise you could write one yourself. you just need to do the following in the start method: bundleContext.registerService( javax.xml.parsers.SAXParserFactory.class.getName(), javax.xml.parsers.SAXParserFactory.newInstance(), null); once this is in place you should be able to use the registry as normal. HTH I tried the same configuration with bundles from release 3.4.2. There I got a NullPointerException: Caused by: java.lang.NullPointerException org.eclipse.core.internal.runtime.ResourceTranslator.getResourceBundle(ResourceTranslator.java:63) org.eclipse.core.internal.registry.osgi.EclipseBundleListener.addBundle(EclipseBundleListener.java:172) org.eclipse.core.internal.registry.osgi.EclipseBundleListener.processBundles(EclipseBundleListener.java:90) org.eclipse.core.internal.registry.osgi.RegistryStrategyOSGI.onStart(RegistryStrategyOSGI.java:210) .. My questions: Is it possible? Anyone tried and has a successful configuration? Which bundles are required? Should I provide more information for my use case? Thanks for your help, Regards, Mike ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev -- Cheers, Stuart ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Using Equinox Declarative services in another OSGI framework
2009/3/9 Alin Dreghiciu adreghi...@gmail.com Hi Guys, I was trying to use Declarative Services implementation from equinox in another OSGi framework and looks like that is not possible. DS has an import on org.eclipse.osgi.service.debug;version=1.0 package that I could only find in the Equinox framework itself. Is it available from somewhere else? Hi Alin, have you looked in the org.eclipse.equinox.supplement bundle? I'm using this to run the Eclipse extension point registry on Felix which also needs that debug import You can find releases of org.eclipse.equinox.supplement here: http://download.eclipse.org/equinox/ just pick from either the 3.4 / 3.5 stream If not, can the org.eclipse.osgi.service.debug be made available at least as a separate bundle, even better together with DebugOptions impl? Another simpler option would be to make this import optional and handle the fact that package is not available in the DS Activator, case when DS can work as in case that no DebugOptions service is available = using system properties. Thanx, -- Alin Dreghiciu http://www.ops4j.org - New Energy for OSS Communities - Open Participation Software. http://www.qi4j.org - New Energy for Java - Domain Driven Development. http://www.codedragons.com - New Energy for Projects - Great People working on Great Projects at Great Places ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev -- Cheers, Stuart ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Loading OSGi from HEAD
2008/11/18 Pascal Rapicault [EMAIL PROTECTED] When I load OSGI from HEAD, the project stops compiling because of unbound value for OSGi/Minimum-1.2. Is there anything in the project itself that could be done to avoid this? see http://dev.eclipse.org/mhonarc/lists/equinox-dev/msg05032.html PaScaL -- Cheers, Stuart ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Bootdelegation question
2008/10/9 Oleg Zhurakousky [EMAIL PROTECTED]
Nice to find you here Rob
Yes I am certain (here are all the options that are set)
-Declipse.ignoreApp=true
-Dosgi.noShutdown=true
-Dosgi.clean=true
One thing I will admit that I am running Equinox within eclipse pde. I'll
try from the command line (not sure if it would make the difference)
see also: http://wiki.eclipse.org/Equinox_Boot_Delegation
(IIRC Equinox doesn't run in strict OSGi mode by default...)
Oleg
On Oct 8, 2008, at 12:36 PM, Rob Harrop wrote:
Oleg,
Are you certain that the Equinox you are running in doesn't have the boot
delegation set to include org.w3c.*?
Rob
- Oleg Zhurakousky [EMAIL PROTECTED] wrote:
If I am reading the spec correctly only java.* are loaded from the
boot class path. All other packages must be declared
with explicit imports.
So something like this without
specifying org.osgi.framework.bootdelegation=org.w3c.*
public void start(BundleContext context) throws Exception {
System. out .println(Class.forName( java.lang.String ));
System. out .println(Class.forName( org.w3c.dom.Attr ));
}
should result in CNFE on the second line.
Well, it actually works just fine without bootdelegation option. I
figured I missed something, so may be some one can steer me in the
right direction.
Cheers
Oleg
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
--
Rob Harrop
SpringSource
Registered in England Wales - Registration Number 5187766
Registered Office: A2 Yeoman Gate, Yeoman Way, Worthing, West Sussex, BN13
3QZ, UK
This e-mail and any attachments transmitted with it are strictly
confidential and intended solely for the person or entity to whom they are
addressed. Unauthorised use, copying, disclosure or distribution is
prohibited. If you receive this e-mail in error please notify the sender
immediately and then delete it along with any attachments. E-mails should be
checked by the recipient to ensure that there are no viruses and Interface21
does not accept any responsibility if this is not done. Any views or
opinions presented are solely those of the author and do not necessarily
represent those of Interface21.
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
--
Cheers, Stuart
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] BSF, Groovy, OSGi - class resolution
2008/10/9 Craig Phillips [EMAIL PROTECTED] Hi, I'm attempting to do groovy a la BSF, as embedded in an OSGi/equinox bundle... I get this unable to resolve class exception on something like the following: import org.osgi.service.log.* // seems to get passed this line def logger = new LogService(); // exception is thrown here I have been surfing for help, but the only thing I get is along the lines of external classpath options (versus using the classes as loaded into the bundle)... Any ideas/suggestions? Thanks, Craig Phillips, Praxis PS - I'm not considering javax.scripting (jsr-223 I believe) at this time... even though you're not considering jsr-223, you might want to look at the OSGi scripting work done by Hendy Irawan: http://wiki.ops4j.org/confluence/display/ops4j/Pax+Script as that might give you some hints how to solve this issue ( afaik Groovy 1.5.7-SNAPSHOT has OSGi manifests ) ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev -- Cheers, Stuart ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Bootdelegation question
2008/10/9 Oleg Zhurakousky [EMAIL PROTECTED]
Thanks guys!!!Looks like starting Equinox under Eclipse makes the
difference, although I can't see what that would be (checked generated
config.ini etc. . . nothing suspicious)
when starting under Eclipse/PDE I believe the following adaptor hook is
used:
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.osgi/eclipseAdaptor/src/org/eclipse/core/runtime/internal/adaptor/EclipseAdaptorHook.java?revision=1.7
and the addProperties() method of this class will programmatically enable
boot delegation if it's not explicitly set in the config...
Starting the same system bundle from the command line renders the expected
results:
java -Dorg.osgi.framework.bootdelegation=org.w3c.* -jar
org.eclipse.osgi_3.4.2.R34x_v20080826-1230.jar -console -clean
osgiss
id State Bundle
0 ACTIVE org.eclipse.osgi_3.4.2.R34x_v20080826-1230
1 INSTALLED OSGiBootDelegationBundle_1.0.0
osgi start 1
class java.lang.String
interface org.w3c.dom.Attr
If bootdelegation option is removed CNFE is thrown during start of the
bundle
Thx
Oleg
On Oct 8, 2008, at 12:57 PM, Stuart McCulloch wrote:
2008/10/9 Oleg Zhurakousky [EMAIL PROTECTED]
Nice to find you here Rob
Yes I am certain (here are all the options that are set)
-Declipse.ignoreApp=true
-Dosgi.noShutdown=true
-Dosgi.clean=true
One thing I will admit that I am running Equinox within eclipse pde. I'll
try from the command line (not sure if it would make the difference)
see also: http://wiki.eclipse.org/Equinox_Boot_Delegation
(IIRC Equinox doesn't run in strict OSGi mode by default...)
Oleg
On Oct 8, 2008, at 12:36 PM, Rob Harrop wrote:
Oleg,
Are you certain that the Equinox you are running in doesn't have the boot
delegation set to include org.w3c.*?
Rob
- Oleg Zhurakousky [EMAIL PROTECTED] wrote:
If I am reading the spec correctly only java.* are loaded from the
boot class path. All other packages must be declared
with explicit imports.
So something like this without
specifying org.osgi.framework.bootdelegation=org.w3c.*
public void start(BundleContext context) throws Exception {
System. out .println(Class.forName( java.lang.String ));
System. out .println(Class.forName( org.w3c.dom.Attr ));
}
should result in CNFE on the second line.
Well, it actually works just fine without bootdelegation option. I
figured I missed something, so may be some one can steer me in the
right direction.
Cheers
Oleg
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
--
Rob Harrop
SpringSource
Registered in England Wales - Registration Number 5187766
Registered Office: A2 Yeoman Gate, Yeoman Way, Worthing, West Sussex, BN13
3QZ, UK
This e-mail and any attachments transmitted with it are strictly
confidential and intended solely for the person or entity to whom they are
addressed. Unauthorised use, copying, disclosure or distribution is
prohibited. If you receive this e-mail in error please notify the sender
immediately and then delete it along with any attachments. E-mails should be
checked by the recipient to ensure that there are no viruses and Interface21
does not accept any responsibility if this is not done. Any views or
opinions presented are solely those of the author and do not necessarily
represent those of Interface21.
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
--
Cheers, Stuart
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
--
Cheers, Stuart
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Is this a bug?
2008/9/24 Niclas Hedhman [EMAIL PROTECTED] On Wed, Sep 24, 2008 at 5:12 PM, Danail Nachev [EMAIL PROTECTED]wrote: If bundles are installed by reference (via reference: URL) Equinox doesn't guarantee anything to bundles which you replace, while they are still running. Although OSGi is considered dynamic, such scenarios are not supported. AFAIK, p2 and old Eclipse Update installs all bundles by reference. Such scenarios can be supported if the bundle was copied to the Equinox storage and not referenced. Bundles which are installed through Bundle.installBundle(String, InputStream) and Bundle.installBundle(String) are copied (unless the URL passed to the installBundle(String) is reference: URL) are copied to the storage. I find this behavior interesting... Is this behavior supported by the specification explicitly, or does it just not cover it?? I couldn't find any explicit mention in the spec, but FWIW we also support the reference: scheme in Felix Cheers Niclas ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev -- Cheers, Stuart ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] java.lang.NoClassDefFoundError: sun/reflect/ReflectionFactory
2008/7/7 Nikhil Sharma [EMAIL PROTECTED]: Hi, When i try to use -* final * ReflectionFactory reflectionFactory = ReflectionFactory.* getReflectionFactory*(); in a bundle it throws a - java.lang.NoClassDefFoundError: sun/reflect/ReflectionFactory What might be the reason for this. do you import the sun.reflect package in your bundle manifest? this is a simplification, but basically the packages that a bundle can see are: 1) those listed under the org.osgi.framework.bootdelegation property AND available from the framework's bootclasspath 2) those contained inside the bundle 3) those imported via Import-Package (or DynamicImport-Package) AND exported from another bundle with matching constraints (versions, attributes, etc.) 4) those visible from another bundle via Require-Bundle but I strongly recommend you read the OSGi spec as it has a much clearer (and definitive) description of package visibility in OSGi, along with pictures! typically the org.osgi.framework.bootdelegation property defaults to java.* so if you don't import the sun.reflect package, or no other bundle exports it, then you will see a NCDF error. if the system bundle (usually bundle 0) exports sun.reflect then you just need to add this package to your Import-Package in the manifest - otherwise you can try adding it to the bootdelegation list, though this is less flexible because your bundle then depends on this property being set correctly as a side note, it is bad practice to depend on sun.* packages as these are private Sun implementation classes, and are not part of the public Java API. these classes may change or disappear between Java releases depending on how Sun feels - and may not be available on non-Sun implementations of Java. HTH ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev -- Cheers, Stuart ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Aspects: problem weaving same class file in different bundles
2008/6/29 Martin Lippert [EMAIL PROTECTED]:
Hi Rowan,
I looked at your example and I think I have found the problem. Your aspect
bundle imports the package widgets and can therefore refer to your class
Widget. But since both widget bundles export the same package including the
same class (Widget), the aspect definition is wired to only one of them.
Therefore the code of the aspect refers to one of those Widget class
definitions (this is standard Java and OSGi behavior).
Now you try to weave both widget bundles. The weaver for widget bundle 1
can weave your class successfully since this weaver sees the same class for
Widget as your aspect bundle. The weaver for widget bundle 2 sees its own
widget class but the aspect bundle is wired to the other one. Therefore the
linkage error happens.
This seems not like a bug in Equinox Aspects nor the AspectJ weaver. Having
the same class (with the same package) within different bundles seems not to
be a nice design anyway. Do you have a specific reason for that? You could
solve your problem by extracting an abstract superclass for your Widget
classes, putting this superclass in a separate bundle and let the aspect
weave against this superclass while having subclasses in your other bundles.
another possibility would be to import and export the 'widgets'
package from both widget bundles, then they would both see
the same class regardless of the order they were installed.
eg:
Export-Package: widgets
Import-Package: org.osgi.framework, widgets
see:
http://www.osgi.org/blog/2007/04/importance-of-exporting-nd-importing.html
Just a first idea, there might be other solutions for your problem. Tell me
more about why you choose this design and we could discuss alternatives, ok?
HTH,
-Martin
sorbus wrote:
Martin wrote:
Hi Rowan,
I assume the problem is that the aspect should weave the same class from
different bundles. For the aspect both Widget classes are visible (because
both should be woven) and the weaver does not know which one to use for
type resolution. But this is just a first guess on the problem... Would you
submit a bug in bugzilla for this issue?
Different aspects in different bundles with more specific supplement
definitions should workaround this problem, but I really would like to
investigate this problem in more detail (therefore the bug). Would be great
if you could create a small test case for this to reproduce.
I think the test case is a good idea (see below). I would rather you
take a look at that first before I submit a bug because I am at the
stage of learning BOTH equinox-aspects AND aspectj so possibly missed
something simple :-)
Description of problem (using a simple test case)
I have a very simple bundle (Widget) which has an Activator class and
a Widget class.
The Activator start() method prints out the Bundle Symbolic Name, then
instantiates a Widget
The Widget class looks like this:
package widgets;
public class Widget {
private String wUID;
public Widget() {
init();
}
private void init() {
wUID = java.util.UUID.randomUUID().toString();
System.out.println(Widget has been assigned UID: + wUID);
}
public void doSomething() {
System.out.println(Widget + wUID + has done something);
}
}
So the constructor calls the init() method which creates a random
UUID, assigns it, and prints it out.
I have two such bundles with a slightly different manifest file
(different Bundle Symbolic Name):
widgetbundle1.jar - Bundle Symbolic Name: Widget_01234
widgetbundle2.jar - Bundle Symbolic Name: Widget_56789
Example manifest file:
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Widget Bundle
Bundle-SymbolicName: Widget_01234
Bundle-Version: 1.0.0
Bundle-ClassPath: .
Bundle-Activator: widgets.Activator
Import-Package: org.osgi.framework
Export-Package: widgets
Bundle-Description: Testing Aspects in OSGi...
The aspects look like this:
package widgetaspects;
import widgets.*;
public aspect MyAspects {
pointcut doInit(Widget w):
execution(void Widget.init(..)) target(w);
after(Widget w) : doInit(w) {
System.out.println(In the AFTER advice for doInit());
System.out.println(target: + thisJoinPoint.getTarget());
System.out.println(this: + thisJoinPoint.getThis());
w.doSomething();
}
}
A pointcut is defined on the execution of the Widget init() method. In
the after advice, the Widget doSomething() method is called.
My aop.xml file looks like this:
?xml version=1.0?
aspectj
aspects
aspect name=widgetaspects.MyAspects/
/aspects
/aspectj
and is installed in org/aspectj/aop.xml in the widget-aspects jar file.
Aspect bundle manifest file:
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Widget Aspects
Bundle-SymbolicName: widgetaspects
Bundle-Version: 1.0.0
Export-Package: widgetaspects,org.aspectj
Import-Package: widgets
Re: [equinox-dev] deployment admin service
2008/6/23 Laura Lozano [EMAIL PROTECTED]: Does it exist any implementation of org.osgi.service.deploymentadmin service in equinox? I can't see it listed here: http://www.eclipse.org/equinox/bundles/ but an implementation is being developed over here: http://svn.apache.org/repos/asf/felix/trunk/deploymentadmin/ which should work with Equinox - you'll need to build it from source as there's no snapshot / release yet... Thank you ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev -- Cheers, Stuart ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Customize versioning scheme
On 07/04/2008, Alex Blewitt [EMAIL PROTECTED] wrote: On Apr 7, 2008, at 13:48, Baptiste MATHUS wrote: Hi all, We're using Eclipse RCP as the platform for our UI. We're almost done with dev and are beginning to look at the packaging/deployment phases. OSGi specifies the org.osgi.framework.Version class to manage versioning by default with x.y.z.qualifier scheme. Our scheme is not very far from it, but not the same, it's something like a.b.c.d.e.qualifier (two numbers more). So my question is simple: is this possible to inject a custom versioning scheme (for example, we could inherit/extend the current Version class to manage our case) ? For bundles, no, the OSGi versioning is fixed. I'm not sure of the point of having so many numbers, but if you have a.b which are on the whole the same throughout other releases, you might like to call your bundle foo-a-b_c.d.e.qualifier instead. You'd lose the connection with the version comparisons but since you'd end up with different named bundles each time, you could easily do that approach. The other thing would be to use some kind of bitshift to represent the numbers e.g. a.b.(c*1024+d*512+e*128).equalifier. another approach would be to enforce a width on both 'd' and 'e' and make them part of the qualifier, for example: 2.7.3.05.02...etc... where the qualifier is XX.XX because the qualifier is sorted using string comparison, it should be ok if you use fixed field widths (you'd have to enforce these field widths yourself and estimate how wide to make them in advance.) you might also want to consider why you need so many version numbers, and whether you could use something else such as a build time-stamp in the qualifier instead (or a version control tag) HTH Alex ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev -- Cheers, Stuart ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Incubator request for Extensions/Services Integration work
On 27/03/2008, Neil Bartlett [EMAIL PROTECTED] wrote: Hello, I have been doing some investigative work recently in the area of integrating extensions with OSGi services. As a result of this, I have developed a small framework for dynamically injecting services into extension objects according to metadata defined via the extension registry. As a very simple example, suppose we have an extension object (e.g. a ViewPart) which has a method setLogReader(LogReaderService). We can declare an injected bean extension as follows: extension point=...injectedBeans bean id=logReaderView class=org...LogReaderView injectSingle interface=org.osgi.service.log.LogReaderService set=setLogReader/ /bean /extension And then the actual view extension as: extension point=org.eclipse.ui.views view class=org...InjectedExtensionFactory:logReaderView name=Log Reader/ /extension This results in all objects instantiated from the log view extension being dynamically injected with the log reader service as it becomes available (and un-injected when it goes away). I would like to request a work area under the Equinox incubator as a home for this code so that others can test it and experiment with this and other approaches to the extensions/services integration problem. Hi Neil, +1 (non-binding) I enjoyed your talk on this at EclipseCon and would be interested in helping out, if needed. -- Cheers, Stuart Regards, Neil ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Bundle Repository Remote Management Tools
On 05/12/2007, OlgaQ [EMAIL PROTECTED] wrote: Does anyone knows if there are open source bundle repository modification tools - I mean some kind of programs for remote adding, removing, searching bundles in repository. I know the OSGi Bundle Repository plug-in for Eclipse, but unfortunately it is not open source. some links that might help: http://www2.osgi.org/Repository/BIndex (now available as open source) http://felix.apache.org/site/apache-felix-osgi-bundle-repository-obr.html there's also Clement Escoffier's Maven plugin for managing local and remote OBRs: http://clement.plop-plop.net/index.php?option=com_contenttask=viewid=26Itemid=37 which is now under the Apache Felix project (sub-project: maven-obr-plugin) HTH Thank you in advance -- View this message in context: http://www.nabble.com/Bundle-Repository-Remote-Management-Tools-tf4935310.html#a14126315 Sent from the Equinox - Dev mailing list archive at Nabble.com. ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev -- Cheers, Stuart ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: AW: [equinox-dev] OSGi Logger Service - Eclipse Plugin Logger
On 12/10/2007, Scott Lewis [EMAIL PROTECTED] wrote: Hi Stuart, Thanks...this is great. Just for my and others info, how much code is pax? well 'pax' is an umbrella project that covers all things OSGi at www.ops4j.org ( ie. logging and http services, provisioning with pax-runner, building projects with pax-construct, dynamic modular wicket with pax-wicket, etc, etc... ) the 'pax-logging-api bundle' is not trivial, but it is really just the logging APIs for log4j, commons, slf4j, avalon, knopflerfish, osgi and it's own API - plus a couple of factory classes the API bundle in total is around 57k, but it can replace any major logging API jar that you might already have on your classpath, so you may find you save space. For the time being my trivial class is just 2500 bytes, so as 'last ditch' ( i.e. if pax or no others are available) it works OK but having something like pax as part of equinox impl would be nice. FYI, it also works well with other OSGi frameworks, such as Knopflerfish and Felix. Scott Stuart McCulloch wrote: On 09/10/2007, Scott Lewis [EMAIL PROTECTED] wrote: Thanks Niclas. I'm really looking for something much more trivial than Pax logging :)...so for the time being I implemented LogService myself. But thanks for the info, I may very well use Pax logging in the future. One question: what does the Pax logging API bundle depend upon? (i.e. extension registry?, others?). The Pax-Logging API bundle only has dependencies on the execution environment (ie. it needs the javax.xml.parsers and org.w3c.dom packages) and on the OSGi framework itself (only the org.osgi.framework, org.osgi.service.event and org.osgi.util.trackerpackages). It uses the OSGi service registry, rather than the Eclipse extension registry. HTH Scott Niclas Hedhman wrote: On Tuesday 09 October 2007 04:28, Scott Lewis wrote: Is there any existing LogService implementation that just prints to System.out/System.err...that is in a bundle present for *all* Equinox impls (not just Eclipse)? Equinox in its purest form has no bundles in it besides the system bundle, and IIRC the internal Equinox logger is not exposed. That is, is there some basic LogService that can be used as a last-ditch logging mechanism (if no other LogService is available)? Pax Logging attempts to provide both OSGi Log Service functionality as well as bridging of third-party legacy APIs such as; JDK Logging Log4J Jakarta Commons Logging Avalon Logging API SLF4J KnopflerFish Log Pax Logging consists of 2 bundles. The API bundle must always be present and is what all the legacy code will 'bind' into when they lookup a logger the respective way. The Service bundle can come and go to allow for upgrade of the Log4J driven bakend, without taking down the entire application. When the Service is not available, the API will revert to System.out (a buffering version is under construction). You find Pax Logging at OPS4J, http://wiki.ops4j.org Cheers ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev -- Cheers, Stuart -- ___ equinox-dev mailing list [EMAIL PROTECTED]://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev -- Cheers, Stuart ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
