Re: [equinox-dev] Equinox with OSGi security?
Hello Thomas,
Thanks a lot, now it works!
Greetings, Marcel
On Jan 24, 2008, at 19:09 , Thomas Watson wrote:
The eclipse.security is only used by the
org.eclipse.equinox.launcher jar. The eclipse.security option is
used by the launcher bootstrap code to indicate that it should setup
a policy which grants itself and the framework ALLPermissions. Then
it sets the java.security.manager to the value of eclipse.security.
Later when the Framework launches it actually will install the
SecurityManager to enable security.
When running without the launcher you need to do a bit more work to
setup your policy file. You can use a very simple policy which
grants AllPermissions to everything like this ...
## BEGIN POLICY FILE ##
grant {
permission java.security.AllPermission;
};
## END POLICY FILE ##
You would then launch equinox with the following command:
java -
Djava
.security
.manager
=org.eclipse.osgi.framework.internal.core.FrameworkSecurityManager -
Djava.security.policy=policy -jar
org.eclipse.osgi_3.4.0.v20080107.jar -console
The java.security.manager property tells the VM what security
manager to load. The java.security.policy property tells the VM what
policy to load to grant permissions. Note that the permissions
granted to the bundles installed into the framework are controled by
the PermissionAdmin and ConditionalPermissionAdmin services. By
default these services will grant all bundles AllPermissions.
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] Tom Watson: Equinox co-lead
Well deserved! Kind regards, Peter Kriens On 24 jan 2008, at 05:36, Jeff McAffer wrote: Recently I was reviewing the Equinox project, the direction and the community around it. One of the things that stood out for me is that Tom Watson has been quietly leading vast swaths of the activity in Equinox from the framework and service implementations to the OSGi spec work and areas in between. Not only does Tom produce great code and designs but he has a great sense of the community and repeatedly performs heroic feats to meet their needs. It is with great pleasure that the Eclipse PMC invited Tom to co- lead the Equinox project and he accepted. Congratulations Tom and thanks for all the great work! ___ 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] [prov] Download manager support for pack200
Also, when we started packing we have had notices memory leakage problems when we were using pack200 through the Java API. | | From: | | | |Jeff McAffer [EMAIL PROTECTED] | | | | To:| | | |Equinox development mailing list equinox-dev@eclipse.org | | | | Date: | | | |01/24/2008 11:36 PM | | | | Subject: | | | |Re: [equinox-dev] [prov] Download manager support for pack200 | | right but there is the practical detail that the exe you need comes with Java 5 or later and the licensing does not likely allow you to ship just the unpack200 exe. But that is a matter for someone's legal team. As John says, the unpack support simply cares whether or not the exe is there. What we really need is an open source implementation of unpack that runs on/with Foundation... Jeff John Arthorne wrote: Just to clarify, the JRE level doesn't matter here. Unpack is performed by a standalone unpack200 executable that doesn't require presence of a JVM. You can run with a Foundation class library, plus a standalone unpack200 executable from Java 5 or Java 6. *Jim Colson [EMAIL PROTECTED]* Sent by: [EMAIL PROTECTED] 01/24/2008 09:18 PM Please respond to Equinox development mailing list equinox-dev@eclipse.org To Equinox development mailing list equinox-dev@eclipse.org cc Equinox development mailing list equinox-dev@eclipse.org, [EMAIL PROTECTED] Subject Re: [equinox-dev] [prov] Download manager support for pack200 how would that work on J2ME (CDC/Foundatoin)? Jim Colson, Chief Architect - IBM Client Software Distinguished Engineer IBM Academy of Technology Board Member - IT Architect Certification 11501 Burnet Rd. Austin, TX 78758 Ph 512-823-7357, Fax 512-838-0962 email: [EMAIL PROTECTED] Admin: Sandra Wallis 512-838-3241 email: [EMAIL PROTECTED] From: Pascal Rapicault [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 01/24/2008 08:11 PM Subject:[equinox-dev] [prov] Download manager support for pack200 I seem to remember that someone was working on adding to support to our download manager to favor downloading pack200'ed artifacts over canonical ones. Did that ever made it into the code? Thx PaScaL ___ 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 ___ 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] is this a service tracker bug?
I see - It's in an IllegalState until you refresh On 25/01/2008, Mark [EMAIL PROTECTED] wrote: Try adding: Import-Package: bundlea.service to the Bundle A manifest. = I just tried the suggestion above - but it blows up? Framework is launched. idState Bundle 0ACTIVE org.eclipse.osgi_3.3.1.R33x_v20070828 1ACTIVE bundleA_1.0.0 2ACTIVE bundleB_1.0.0 osgi stop 1 removedService osgi update 1 osgi ss Framework is launched. idState Bundle 0ACTIVE org.eclipse.osgi_3.3.1.R33x_v20070828 1INSTALLED bundleA_1.0.0 2ACTIVE bundleB_1.0.0 osgi start 1 org.osgi.framework.BundleException: Exception in bundlea.Activator.start() of bundle bundleA. at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator( BundleContextImpl.java:1018) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start( BundleContextImpl.java:974) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker( BundleHost.java:346) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start( AbstractBundle.java:260) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start( AbstractBundle.java:252) at org.eclipse.osgi.framework.internal.core.FrameworkCommandProvider._start( FrameworkCommandProvider.java:260) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.eclipse.osgi.framework.internal.core.FrameworkCommandInterpreter.execute (FrameworkCommandInterpreter.java:150) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.docommand (FrameworkConsole.java:291) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.console( FrameworkConsole.java:276) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.run( FrameworkConsole.java:218) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.IllegalStateException: The state indicates the bundle is resolved at org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureMessage (AbstractBundle.java:1376) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker( BundleHost.java:305) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start( AbstractBundle.java:260) at org.eclipse.osgi.framework.util.SecureAction.start( SecureAction.java:400) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass (EclipseLazyStarter.java:111) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass (ClasspathManager.java:417) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass( DefaultClassLoader.java:189) at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass( BundleLoader.java:340) at org.eclipse.osgi.framework.internal.core.SingleSourcePackage.loadClass( SingleSourcePackage.java:37) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClassInternal( BundleLoader.java:396) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass( BundleLoader.java:369) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass( BundleLoader.java:357) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass( DefaultClassLoader.java:83) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at bundlea.Activator.start(Activator.java:12) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run( BundleContextImpl.java:999) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator( BundleContextImpl.java:993) ... 14 more Nested Exception: java.lang.IllegalStateException: The state indicates the bundle is resolved at org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureMessage (AbstractBundle.java:1376) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker( BundleHost.java:305) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start( AbstractBundle.java:260) at org.eclipse.osgi.framework.util.SecureAction.start( SecureAction.java:400) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass (EclipseLazyStarter.java:111) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass (ClasspathManager.java:417) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass( DefaultClassLoader.java:189) at
Re: [equinox-dev] is this a service tracker bug?
Try adding: Import-Package: bundlea.service to the Bundle A manifest. = I just tried the suggestion above - but it blows up? Framework is launched. idState Bundle 0ACTIVE org.eclipse.osgi_3.3.1.R33x_v20070828 1ACTIVE bundleA_1.0.0 2ACTIVE bundleB_1.0.0 osgi stop 1 removedService osgi update 1 osgi ss Framework is launched. idState Bundle 0ACTIVE org.eclipse.osgi_3.3.1.R33x_v20070828 1INSTALLED bundleA_1.0.0 2ACTIVE bundleB_1.0.0 osgi start 1 org.osgi.framework.BundleException: Exception in bundlea.Activator.start() of bundle bundleA. at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator( BundleContextImpl.java:1018) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start( BundleContextImpl.java:974) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker( BundleHost.java:346) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start( AbstractBundle.java:260) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start( AbstractBundle.java:252) at org.eclipse.osgi.framework.internal.core.FrameworkCommandProvider._start( FrameworkCommandProvider.java:260) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke( DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.eclipse.osgi.framework.internal.core.FrameworkCommandInterpreter.execute (FrameworkCommandInterpreter.java:150) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.docommand( FrameworkConsole.java:291) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.console( FrameworkConsole.java:276) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.run( FrameworkConsole.java:218) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.IllegalStateException: The state indicates the bundle is resolved at org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureMessage (AbstractBundle.java:1376) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker( BundleHost.java:305) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start( AbstractBundle.java:260) at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java :400) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass (EclipseLazyStarter.java:111) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass( ClasspathManager.java:417) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass( DefaultClassLoader.java:189) at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass( BundleLoader.java:340) at org.eclipse.osgi.framework.internal.core.SingleSourcePackage.loadClass( SingleSourcePackage.java:37) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClassInternal( BundleLoader.java:396) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass( BundleLoader.java:369) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass( BundleLoader.java:357) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass( DefaultClassLoader.java:83) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at bundlea.Activator.start(Activator.java:12) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run( BundleContextImpl.java:999) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator( BundleContextImpl.java:993) ... 14 more Nested Exception: java.lang.IllegalStateException: The state indicates the bundle is resolved at org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureMessage (AbstractBundle.java:1376) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker( BundleHost.java:305) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start( AbstractBundle.java:260) at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java :400) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass (EclipseLazyStarter.java:111) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass( ClasspathManager.java:417) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass( DefaultClassLoader.java:189) at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass( BundleLoader.java:340) at org.eclipse.osgi.framework.internal.core.SingleSourcePackage.loadClass( SingleSourcePackage.java:37) at
Re: [equinox-dev] [prov] Download manager support for pack200
I was thinking a new separate classloader containing just the Pack200 classes. We would still want to delegate to the bootclassloader for everything else. However, I doubt the Pack200 classes are by themselves in their own jar that we could just create a URLClassloader for. This was really just an idea and I haven't really thought very hard about the details :) -Andrew Thomas Watson [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 01/25/2008 11:54 AM Please respond to Equinox development mailing list equinox-dev@eclipse.org To Equinox development mailing list equinox-dev@eclipse.org cc Subject Re: [equinox-dev] [prov] Download manager support for pack200 If the Pack200 class is loaded from the VM then it will fall under the boot class loader. There is no way we can throw that class loader away. Are you suggesting that we could somehow load this class from an isolated class loader that is not connected to the boot class loader? Tom Andrew Niefer ---01/25/2008 09:57:39 AM---As Pascal mentioned, when we first started experimenting with Pack200 we had memory problems. It seemed that Pack200's interna From: Andrew Niefer [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 01/25/2008 09:57 AM Subject: Re: [equinox-dev] [prov] Download manager support for pack200 As Pascal mentioned, when we first started experimenting with Pack200 we had memory problems. It seemed that Pack200's internal data was static and not cleared between each jar that was packed. So once we had packed a reasonable number of jars we started running out of memory. It could be that we had been doing something wrong. It is also possible that we could work around this by playing with class loaders (under the assumption that if the classloader was garbage collected, all that static memory would go away). -Andrew Thomas Hallgren [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 01/25/2008 02:53 AM Please respond to Equinox development mailing list equinox-dev@eclipse.org To Equinox development mailing list equinox-dev@eclipse.org cc Subject Re: [equinox-dev] [prov] Download manager support for pack200 Just out of curiosity, why do you use the external binary to do the pack/unpack and not the java.util.jar.Pack200 class? It seems to me that a fragment that is EE dependent (require Java 1.5 or higher) would be ideal here. Those who run lower then Java 5 simply would not have pack200 which is kind of natural isn't it? - thomas Jeff McAffer wrote: right but there is the practical detail that the exe you need comes with Java 5 or later and the licensing does not likely allow you to ship just the unpack200 exe. But that is a matter for someone's legal team. As John says, the unpack support simply cares whether or not the exe is there. What we really need is an open source implementation of unpack that runs on/with Foundation... Jeff John Arthorne wrote: Just to clarify, the JRE level doesn't matter here. Unpack is performed by a standalone unpack200 executable that doesn't require presence of a JVM. You can run with a Foundation class library, plus a standalone unpack200 executable from Java 5 or Java 6. *Jim Colson [EMAIL PROTECTED]* Sent by: [EMAIL PROTECTED] 01/24/2008 09:18 PM Please respond to Equinox development mailing list equinox-dev@eclipse.org To Equinox development mailing list equinox-dev@eclipse.org cc Equinox development mailing list equinox-dev@eclipse.org, [EMAIL PROTECTED] Subject Re: [equinox-dev] [prov] Download manager support for pack200 how would that work on J2ME (CDC/Foundatoin)? Jim Colson, Chief Architect - IBM Client Software Distinguished Engineer IBM Academy of Technology Board Member - IT Architect Certification 11501 Burnet Rd. Austin, TX 78758 Ph 512-823-7357, Fax 512-838-0962 email: [EMAIL PROTECTED] Admin: Sandra Wallis 512-838-3241 email: [EMAIL PROTECTED] From: Pascal Rapicault [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 01/24/2008 08:11 PM Subject: [equinox-dev] [prov] Download manager support for pack200 I seem to remember that someone was working on adding to support to our download manager to favor downloading pack200'ed artifacts over canonical ones. Did that ever made it into the code? Thx PaScaL ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org
Re: [equinox-dev] is this a service tracker bug?
Mark, Since your service interface (IA.java) is contained within bundleA, bundleB requires a package import from bundleA. The effect that you're seeing is that the old version of bundleA remains in the system and is still used by bundleB after you call update. Therefore you now have two instances of bundleA in the system: the old one, still used by bundleB, and the new refreshed one. Since you called 'refresh', the old bundleA was stopped, and so were any registered services (which is why you see 'removedService'). The new bundleA was also started, and a new IA service was registered. However, since bundleB is still using the package import from the old bundleA, it does not get notified of the new bundleA's service (refer to ServiceListener vs. AllServiceListener). Calling 'refresh' instructs the framework to perform the steps outlined at http://www2.osgi.org/javadoc/r4/org/osgi/service/packageadmin/PackageAdmin.html#refreshPackages(org.osgi.framework.Bundle[]). This in turn stops bundleB, gets rid of the old bundleA and links bundleB to the new bundleA's package source. When bundleB is restarted and linked to the new bundleA, it can once again see the IA service. Sorry if that was a bit confusing.. maybe someone else can clarify a bit more. -Jeremy On Jan 25, 2008 11:33 AM, Mark [EMAIL PROTECTED] wrote: This is driving me mad. I have two bundles A and B. B track the service offered by A. However if I call update on A then I get a remove Service notification but no add Service notification - that is until I issue a refresh command ? is this a bug? I have written the same simple code 10 time .. see the results. I have attached the two bundles and the two eclipse plugin projects (as one zip) - just in case a Eclipse/OSGi guru like yourself can figure it out? C:\egjava -jar equinox.osgi.jar -console osgi ss Framework is launched. id State Bundle 0 ACTIVE org.eclipse.osgi_3.4.0.v20071207 osgi install file:bundleA_1.0.0.jar Bundle id is 1 osgi install file:bundleB_1.0.0.jar Bundle id is 2 osgi ss Framework is launched. id State Bundle 0 ACTIVE org.eclipse.osgi_3.4.0.v20071207 1 INSTALLED bundleA_1.0.0 2 INSTALLED bundleB_1.0.0 osgi start 1 osgi start 2 addingService osgi stop 1 removedService osgi start 1 addingService osgi update 1 removedService - no add ! osgi stop 2 osgi start 2 osgi refresh - Only get add after refresh osgi addingService osgi On 25/01/2008, Neil Bartlett [EMAIL PROTECTED] wrote: Hi Mark, Many thanks for your kind words! Regarding the service tracker problem... that's not the behaviour I would expect to see, and I've just put together a small test case which prints a message in the addingService, removedService and modifiedService methods of the ServiceTracker. When I update the bundle that registered the service, I see the following: osgi update 5 Removed service Added service osgi Which seems to be the way it should work. I suggest posting a message to the equinox-dev mailing list ( https://dev.eclipse.org/mailman/listinfo/equinox-dev) explaining the problem in detail and including a minimal code sample that reproduces the problem. Regards, Neil On 25 Jan 2008, at 13:42, Mark wrote: Neil, First off I have to thank you in a big way, because it was you articles that got me up and running on OSGI. I am also glad that you are putting together a book... because I was thinking about it myself...in practice or in action!, would you like some help? ..Anyway the reason for this mail... I was looking at the Listeners Considered Harmful: The Whiteboard Pattern white paper, and I put together a very simple two bundle example (on Equinox), Bundle A (offers a service) Bundle B (consumes service A, using a Service Tracker) So far so good, and not exactly rocket science. However this morning I discovered that if you update A - then you must refresh A in order for B to receive the added service event. This came as a surprise, go I Googled a while, and came up short. So I was wondering if you had some words of widom for me on this ? Kind Regards Mark ___ 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] [prov] Download manager support for pack200
If the Pack200 class is loaded from the VM then it will fall under the boot class loader. There is no way we can throw that class loader away. Are you suggesting that we could somehow load this class from an isolated class loader that is not connected to the boot class loader? Tom From: Andrew Niefer [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 01/25/2008 09:57 AM Subject:Re: [equinox-dev] [prov] Download manager support for pack200 As Pascal mentioned, when we first started experimenting with Pack200 we had memory problems. It seemed that Pack200's internal data was static and not cleared between each jar that was packed. So once we had packed a reasonable number of jars we started running out of memory. It could be that we had been doing something wrong. It is also possible that we could work around this by playing with class loaders (under the assumption that if the classloader was garbage collected, all that static memory would go away). -Andrew Thomas Hallgren [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED]To Equinox development mailing list equinox-dev@eclipse.org 01/25/2008 02:53 AMcc Subject Please respond toRe: [equinox-dev] [prov] Equinox development mailing listDownload manager support for equinox-dev@eclipse.orgpack200 Just out of curiosity, why do you use the external binary to do the pack/unpack and not the java.util.jar.Pack200 class? It seems to me that a fragment that is EE dependent (require Java 1.5 or higher) would be ideal here. Those who run lower then Java 5 simply would not have pack200 which is kind of natural isn't it? - thomas Jeff McAffer wrote: right but there is the practical detail that the exe you need comes with Java 5 or later and the licensing does not likely allow you to ship just the unpack200 exe. But that is a matter for someone's legal team. As John says, the unpack support simply cares whether or not the exe is there. What we really need is an open source implementation of unpack that runs on/with Foundation... Jeff John Arthorne wrote: Just to clarify, the JRE level doesn't matter here. Unpack is performed by a standalone unpack200 executable that doesn't require presence of a JVM. You can run with a Foundation class library, plus a standalone unpack200 executable from Java 5 or Java 6. *Jim Colson [EMAIL PROTECTED]* Sent by: [EMAIL PROTECTED] 01/24/2008 09:18 PM Please respond to Equinox development mailing list equinox-dev@eclipse.org To Equinox development mailing list equinox-dev@eclipse.org cc Equinox development mailing list equinox-dev@eclipse.org, [EMAIL PROTECTED] Subject Re: [equinox-dev] [prov] Download manager support for pack200 how would that work on J2ME (CDC/Foundatoin)? Jim Colson, Chief Architect - IBM Client Software Distinguished Engineer IBM Academy of Technology Board Member - IT Architect Certification 11501 Burnet Rd. Austin, TX 78758 Ph 512-823-7357, Fax 512-838-0962 email: [EMAIL PROTECTED] Admin: Sandra Wallis 512-838-3241 email: [EMAIL PROTECTED] From: Pascal Rapicault [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 01/24/2008 08:11 PM
[equinox-dev] Weekly development meeting details
We have a new number for the weekly equinox development meeting, see the wiki for details: http://wiki.eclipse.org/Equinox_Meeting_Minutes#Call-in_Information All contributors/committers interested in helping with the development of Equinox are welcome to join. - ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] is this a service tracker bug?
Mark, I opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=216648 for you. I tried to CC you to the bug but I noticed you did not seem to have a bugzilla e-mail, unless you use a different e-mail for bugzilla than the one you use to post to equinox-dev. Tom From: Mark [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 01/25/2008 02:43 PM Subject:Re: [equinox-dev] is this a service tracker bug? :( I'll file a report - one other solution pointed out was to seperate interface (api) from the impl and the client. So I guess I should create A, B, and C (A)pi, Impl-(B)undle, and (C)lient Regards osgi ss Framework is launched. idState Bundle 0ACTIVE org.eclipse.osgi_3.3.1.R33x_v20070828 1ACTIVE bundleA_1.0.0 2ACTIVE bundleB_1.0.0 osgi update 1 removedService osgi update 1 osgi ss Framework is launched. idState Bundle 0ACTIVE org.eclipse.osgi_3.3.1.R33x_v20070828 1INSTALLED bundleA_1.0.0 2ACTIVE bundleB_1.0.0 osgi start 1 org.osgi.framework.BundleException: Exception in bundlea.Activator.start() of bundle bundleA. at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:1018) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:974) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:346) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:260) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:252) at org.eclipse.osgi.framework.internal.core.FrameworkCommandProvider._start(FrameworkCommandProvider.java:260) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.eclipse.osgi.framework.internal.core.FrameworkCommandInterpreter.execute(FrameworkCommandInterpreter.java:150) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.docommand(FrameworkConsole.java:291) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.console(FrameworkConsole.java:276) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.run(FrameworkConsole.java:218) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.IllegalStateException: The state indicates the bundle is resolved at org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureMessage(AbstractBundle.java:1376) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:305) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:260) at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:400) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:111) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:417) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:189) at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java:340) at org.eclipse.osgi.framework.internal.core.SingleSourcePackage.loadClass(SingleSourcePackage.java:37) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClassInternal(BundleLoader.java:396) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:369) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:357) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:83) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at bundlea.Activator.start(Activator.java:12) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:999) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:993) ... 14 more Nested Exception: java.lang.IllegalStateException: The state indicates the bundle is resolved at
Re: [equinox-dev] is this a service tracker bug?
But you should not have to refresh. That is the whole point of importing the package which is exported. So that A' can import it from A which is where B imports it from. I think the IllegalStateException is is a bug in Equinox. -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] office: +1 386 848 1781 mobile: +1 386 848 3788 From: Mark [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 2008-01-25 13:06 Subject: Re: [equinox-dev] is this a service tracker bug? I see - It's in an IllegalState until you refresh On 25/01/2008, Mark [EMAIL PROTECTED] wrote: Try adding: Import-Package: bundlea.service to the Bundle A manifest. = I just tried the suggestion above - but it blows up? Framework is launched. idState Bundle 0ACTIVE org.eclipse.osgi_3.3.1.R33x_v20070828 1ACTIVE bundleA_1.0.0 2ACTIVE bundleB_1.0.0 osgi stop 1 removedService osgi update 1 osgi ss Framework is launched. idState Bundle 0ACTIVE org.eclipse.osgi_3.3.1.R33x_v20070828 1INSTALLED bundleA_1.0.0 2ACTIVE bundleB_1.0.0 osgi start 1 org.osgi.framework.BundleException: Exception in bundlea.Activator.start() of bundle bundleA. at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:1018) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:974) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:346) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:260) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:252) at org.eclipse.osgi.framework.internal.core.FrameworkCommandProvider._start(FrameworkCommandProvider.java:260) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.eclipse.osgi.framework.internal.core.FrameworkCommandInterpreter.execute(FrameworkCommandInterpreter.java:150) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.docommand(FrameworkConsole.java:291) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.console(FrameworkConsole.java:276) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.run(FrameworkConsole.java:218) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.IllegalStateException: The state indicates the bundle is resolved at org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureMessage(AbstractBundle.java:1376) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:305) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:260) at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:400) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:111) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:417) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:189) at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java:340) at org.eclipse.osgi.framework.internal.core.SingleSourcePackage.loadClass(SingleSourcePackage.java:37) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClassInternal(BundleLoader.java:396) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:369) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:357) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:83) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at bundlea.Activator.start(Activator.java:12) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:999) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:993) ... 14 more Nested Exception: java.lang.IllegalStateException: The state indicates the bundle is resolved at org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureMessage(AbstractBundle.java:1376) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:305) at
Re: [equinox-dev] is this a service tracker bug?
That seems to be a bug in Equinox. You may wish to file a bug report. For giggles, try update 1 without stopping it first. The update operation will automatically stop and restart the updated bundle. Note: in order for import and exporting the package to work here, the exported package in A' must be backwards compatible with the exported package in A. This is because the remaining code in A' will be implementing/using the interface from A. -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] office: +1 386 848 1781 mobile: +1 386 848 3788 From: Mark [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 2008-01-25 12:59 Subject: Re: [equinox-dev] is this a service tracker bug? Try adding: Import-Package: bundlea.service to the Bundle A manifest. = I just tried the suggestion above - but it blows up? Framework is launched. idState Bundle 0ACTIVE org.eclipse.osgi_3.3.1.R33x_v20070828 1ACTIVE bundleA_1.0.0 2ACTIVE bundleB_1.0.0 osgi stop 1 removedService osgi update 1 osgi ss Framework is launched. idState Bundle 0ACTIVE org.eclipse.osgi_3.3.1.R33x_v20070828 1INSTALLED bundleA_1.0.0 2ACTIVE bundleB_1.0.0 osgi start 1 org.osgi.framework.BundleException: Exception in bundlea.Activator.start() of bundle bundleA. at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:1018) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:974) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:346) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:260) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:252) at org.eclipse.osgi.framework.internal.core.FrameworkCommandProvider._start(FrameworkCommandProvider.java:260) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.eclipse.osgi.framework.internal.core.FrameworkCommandInterpreter.execute(FrameworkCommandInterpreter.java:150) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.docommand(FrameworkConsole.java:291) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.console(FrameworkConsole.java:276) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.run(FrameworkConsole.java:218) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.IllegalStateException: The state indicates the bundle is resolved at org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureMessage(AbstractBundle.java:1376) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:305) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:260) at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:400) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:111) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:417) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:189) at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java:340) at org.eclipse.osgi.framework.internal.core.SingleSourcePackage.loadClass(SingleSourcePackage.java:37) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClassInternal(BundleLoader.java:396) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:369) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:357) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:83) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at bundlea.Activator.start(Activator.java:12) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:999) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:993) ... 14 more Nested Exception: java.lang.IllegalStateException: The state indicates the bundle is resolved at org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureMessage(AbstractBundle.java:1376) at
Re: [equinox-dev] is this a service tracker bug?
Thanks. So that's expected behaviour - and all makes sense. Regards Mark On 25/01/2008, Jeremy Volkman [EMAIL PROTECTED] wrote: Mark, Since your service interface (IA.java) is contained within bundleA, bundleB requires a package import from bundleA. The effect that you're seeing is that the old version of bundleA remains in the system and is still used by bundleB after you call update. Therefore you now have two instances of bundleA in the system: the old one, still used by bundleB, and the new refreshed one. Since you called 'refresh', the old bundleA was stopped, and so were any registered services (which is why you see 'removedService'). The new bundleA was also started, and a new IA service was registered. However, since bundleB is still using the package import from the old bundleA, it does not get notified of the new bundleA's service (refer to ServiceListener vs. AllServiceListener). Calling 'refresh' instructs the framework to perform the steps outlined at http://www2.osgi.org/javadoc/r4/org/osgi/service/packageadmin/PackageAdmin.html#refreshPackages(org.osgi.framework.Bundle[]) . This in turn stops bundleB, gets rid of the old bundleA and links bundleB to the new bundleA's package source. When bundleB is restarted and linked to the new bundleA, it can once again see the IA service. Sorry if that was a bit confusing.. maybe someone else can clarify a bit more. -Jeremy On Jan 25, 2008 11:33 AM, Mark [EMAIL PROTECTED] wrote: This is driving me mad. I have two bundles A and B. B track the service offered by A. However if I call update on A then I get a remove Service notification but no add Service notification - that is until I issue a refresh command ? is this a bug? I have written the same simple code 10 time .. see the results. I have attached the two bundles and the two eclipse plugin projects (as one zip) - just in case a Eclipse/OSGi guru like yourself can figure it out? C:\egjava -jar equinox.osgi.jar -console osgi ss Framework is launched. id State Bundle 0 ACTIVE org.eclipse.osgi_3.4.0.v20071207 osgi install file:bundleA_1.0.0.jar Bundle id is 1 osgi install file:bundleB_1.0.0.jar Bundle id is 2 osgi ss Framework is launched. id State Bundle 0 ACTIVE org.eclipse.osgi_3.4.0.v20071207 1 INSTALLED bundleA_1.0.0 2 INSTALLED bundleB_1.0.0 osgi start 1 osgi start 2 addingService osgi stop 1 removedService osgi start 1 addingService osgi update 1 removedService - no add ! osgi stop 2 osgi start 2 osgi refresh - Only get add after refresh osgi addingService osgi On 25/01/2008, Neil Bartlett [EMAIL PROTECTED] wrote: Hi Mark, Many thanks for your kind words! Regarding the service tracker problem... that's not the behaviour I would expect to see, and I've just put together a small test case which prints a message in the addingService, removedService and modifiedService methods of the ServiceTracker. When I update the bundle that registered the service, I see the following: osgi update 5 Removed service Added service osgi Which seems to be the way it should work. I suggest posting a message to the equinox-dev mailing list ( https://dev.eclipse.org/mailman/listinfo/equinox-dev) explaining the problem in detail and including a minimal code sample that reproduces the problem. Regards, Neil On 25 Jan 2008, at 13:42, Mark wrote: Neil, First off I have to thank you in a big way, because it was you articles that got me up and running on OSGI. I am also glad that you are putting together a book... because I was thinking about it myself...in practice or in action!, would you like some help? ..Anyway the reason for this mail... I was looking at the Listeners Considered Harmful: The Whiteboard Pattern white paper, and I put together a very simple two bundle example (on Equinox), Bundle A (offers a service) Bundle B (consumes service A, using a Service Tracker) So far so good, and not exactly rocket science. However this morning I discovered that if you update A - then you must refresh A in order for B to receive the added service event. This came as a surprise, go I Googled a while, and came up short. So I was wondering if you had some words of widom for me on this ? Kind Regards Mark ___ 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] is this a service tracker bug?
Try adding: Import-Package: bundlea.service to the Bundle A manifest. Then when bundle A is updated to A', A' will import the package from A which is where bundle B is importing it. So bundle B can see the service from A' since it implements the interface from A. (This follows from Tom Watson's explanation.) See http://www.osgi.org/blog/2007/04/importance-of-exporting-nd-importing.html -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] office: +1 386 848 1781 mobile: +1 386 848 3788 ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] is this a service tracker bug?
Mark, This is because of the pending removal of the old class loader from bundle A which bundle B is still wired to for package bundlea.service. You do not see the new service from bundle B because you would get a ClassCastException. The Framework filters out services that it knows you do not have the correct package wiring for. The new content for the service is loaded from the new class loader of Bundle A. But since Bundle B is still wired to the old content of Bundle A it will not see the service until it is refreshed. A refresh operation will rewire Bundle B so that it gets the new content from Bundle A and everybody will be happy. Tom [EMAIL PROTECTED] wrote on 01/25/2008 10:33:33 AM: This is driving me mad. I have two bundles A and B. B track the service offered by A. However if I call update on A then I get a remove Service notification but no add Service notification - that is until I issue a refresh command ? is this a bug? I have written the same simple code 10 time .. see the results. I have attached the two bundles and the two eclipse plugin projects (as one zip) - just in case a Eclipse/OSGi guru like yourself can figure it out? [image removed] [image removed] C:\egjava -jar equinox.osgi.jar -console osgi ss Framework is launched. id State Bundle 0 ACTIVE org.eclipse.osgi_3.4.0.v20071207 osgi install file:bundleA_1.0.0.jar Bundle id is 1 osgi install file:bundleB_1.0.0.jar Bundle id is 2 osgi ss Framework is launched. id State Bundle 0 ACTIVE org.eclipse.osgi_3.4.0.v20071207 1 INSTALLED bundleA_1.0.0 2 INSTALLED bundleB_1.0.0 osgi start 1 osgi start 2 addingService osgi stop 1 removedService osgi start 1 addingService osgi update 1 removedService - no add ! osgi stop 2 osgi start 2 osgi refresh - Only get add after refresh osgi addingService osgi On 25/01/2008, Neil Bartlett [EMAIL PROTECTED] wrote: Hi Mark, Many thanks for your kind words! Regarding the service tracker problem... that's not the behaviour I would expect to see, and I've just put together a small test case which prints a message in the addingService, removedService and modifiedService methods of the ServiceTracker. When I update the bundle that registered the service, I see the following: osgi update 5 Removed service Added service osgi Which seems to be the way it should work. I suggest posting a message to the equinox-dev mailing list ( https://dev.eclipse.org/ mailman/listinfo/equinox-dev) explaining the problem in detail and including a minimal code sample that reproduces the problem. Regards, Neil On 25 Jan 2008, at 13:42, Mark wrote: Neil, First off I have to thank you in a big way, because it was you articles that got me up and running on OSGI. I am also glad that you are putting together a book... because I was thinking about it myself...in practice or in action!, would you like some help? ..Anyway the reason for this mail... I was looking at the Listeners Considered Harmful: The Whiteboard Pattern white paper, and I put together a very simple two bundle example (on Equinox), Bundle A (offers a service) Bundle B (consumes service A, using a Service Tracker) So far so good, and not exactly rocket science. However this morning I discovered that if you update A - then you must refresh A in order for B to receive the added service event. This came as a surprise, go I Googled a while, and came up short. So I was wondering if you had some words of widom for me on this ? Kind Regards Mark [attachment bundleA_1.0.0.jar deleted by Thomas Watson/Austin/IBM] [attachment bundleB_1.0.0.jar deleted by Thomas Watson/Austin/IBM] [attachment eclipe-projects.zip deleted by Thomas Watson/Austin/IBM] ___ 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] [prov] Download manager support for pack200
As Pascal mentioned, when we first started experimenting with Pack200 we had memory problems. It seemed that Pack200's internal data was static and not cleared between each jar that was packed. So once we had packed a reasonable number of jars we started running out of memory. It could be that we had been doing something wrong. It is also possible that we could work around this by playing with class loaders (under the assumption that if the classloader was garbage collected, all that static memory would go away). -Andrew Thomas Hallgren [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 01/25/2008 02:53 AM Please respond to Equinox development mailing list equinox-dev@eclipse.org To Equinox development mailing list equinox-dev@eclipse.org cc Subject Re: [equinox-dev] [prov] Download manager support for pack200 Just out of curiosity, why do you use the external binary to do the pack/unpack and not the java.util.jar.Pack200 class? It seems to me that a fragment that is EE dependent (require Java 1.5 or higher) would be ideal here. Those who run lower then Java 5 simply would not have pack200 which is kind of natural isn't it? - thomas Jeff McAffer wrote: right but there is the practical detail that the exe you need comes with Java 5 or later and the licensing does not likely allow you to ship just the unpack200 exe. But that is a matter for someone's legal team. As John says, the unpack support simply cares whether or not the exe is there. What we really need is an open source implementation of unpack that runs on/with Foundation... Jeff John Arthorne wrote: Just to clarify, the JRE level doesn't matter here. Unpack is performed by a standalone unpack200 executable that doesn't require presence of a JVM. You can run with a Foundation class library, plus a standalone unpack200 executable from Java 5 or Java 6. *Jim Colson [EMAIL PROTECTED]* Sent by: [EMAIL PROTECTED] 01/24/2008 09:18 PM Please respond to Equinox development mailing list equinox-dev@eclipse.org To Equinox development mailing list equinox-dev@eclipse.org cc Equinox development mailing list equinox-dev@eclipse.org, [EMAIL PROTECTED] Subject Re: [equinox-dev] [prov] Download manager support for pack200 how would that work on J2ME (CDC/Foundatoin)? Jim Colson, Chief Architect - IBM Client Software Distinguished Engineer IBM Academy of Technology Board Member - IT Architect Certification 11501 Burnet Rd. Austin, TX 78758 Ph 512-823-7357, Fax 512-838-0962 email: [EMAIL PROTECTED] Admin: Sandra Wallis 512-838-3241 email: [EMAIL PROTECTED] From: Pascal Rapicault [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 01/24/2008 08:11 PM Subject: [equinox-dev] [prov] Download manager support for pack200 I seem to remember that someone was working on adding to support to our download manager to favor downloading pack200'ed artifacts over canonical ones. Did that ever made it into the code? Thx PaScaL ___ 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 ___ 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] is this a service tracker bug?
Which is the prime reason why you should also import your service package in A, so that it can wire to other providers if they are available. - richard Jeremy Volkman wrote: Mark, Since your service interface (IA.java) is contained within bundleA, bundleB requires a package import from bundleA. The effect that you're seeing is that the old version of bundleA remains in the system and is still used by bundleB after you call update. Therefore you now have two instances of bundleA in the system: the old one, still used by bundleB, and the new refreshed one. Since you called 'refresh', the old bundleA was stopped, and so were any registered services (which is why you see 'removedService'). The new bundleA was also started, and a new IA service was registered. However, since bundleB is still using the package import from the old bundleA, it does not get notified of the new bundleA's service (refer to ServiceListener vs. AllServiceListener). Calling 'refresh' instructs the framework to perform the steps outlined at http://www2.osgi.org/javadoc/r4/org/osgi/service/packageadmin/PackageAdmin.html#refreshPackages(org.osgi.framework.Bundle[]). This in turn stops bundleB, gets rid of the old bundleA and links bundleB to the new bundleA's package source. When bundleB is restarted and linked to the new bundleA, it can once again see the IA service. Sorry if that was a bit confusing.. maybe someone else can clarify a bit more. -Jeremy On Jan 25, 2008 11:33 AM, Mark [EMAIL PROTECTED] wrote: This is driving me mad. I have two bundles A and B. B track the service offered by A. However if I call update on A then I get a remove Service notification but no add Service notification - that is until I issue a refresh command ? is this a bug? I have written the same simple code 10 time .. see the results. I have attached the two bundles and the two eclipse plugin projects (as one zip) - just in case a Eclipse/OSGi guru like yourself can figure it out? C:\egjava -jar equinox.osgi.jar -console osgi ss Framework is launched. id State Bundle 0 ACTIVE org.eclipse.osgi_3.4.0.v20071207 osgi install file:bundleA_1.0.0.jar Bundle id is 1 osgi install file:bundleB_1.0.0.jar Bundle id is 2 osgi ss Framework is launched. id State Bundle 0 ACTIVE org.eclipse.osgi_3.4.0.v20071207 1 INSTALLED bundleA_1.0.0 2 INSTALLED bundleB_1.0.0 osgi start 1 osgi start 2 addingService osgi stop 1 removedService osgi start 1 addingService osgi update 1 removedService - no add ! osgi stop 2 osgi start 2 osgi refresh - Only get add after refresh osgi addingService osgi On 25/01/2008, Neil Bartlett [EMAIL PROTECTED] wrote: Hi Mark, Many thanks for your kind words! Regarding the service tracker problem... that's not the behaviour I would expect to see, and I've just put together a small test case which prints a message in the addingService, removedService and modifiedService methods of the ServiceTracker. When I update the bundle that registered the service, I see the following: osgi update 5 Removed service Added service osgi Which seems to be the way it should work. I suggest posting a message to the equinox-dev mailing list ( https://dev.eclipse.org/mailman/listinfo/equinox-dev) explaining the problem in detail and including a minimal code sample that reproduces the problem. Regards, Neil On 25 Jan 2008, at 13:42, Mark wrote: Neil, First off I have to thank you in a big way, because it was you articles that got me up and running on OSGI. I am also glad that you are putting together a book... because I was thinking about it myself...in practice or in action!, would you like some help? ..Anyway the reason for this mail... I was looking at the Listeners Considered Harmful: The Whiteboard Pattern white paper, and I put together a very simple two bundle example (on Equinox), Bundle A (offers a service) Bundle B (consumes service A, using a Service Tracker) So far so good, and not exactly rocket science. However this morning I discovered that if you update A - then you must refresh A in order for B to receive the added service event. This came as a surprise, go I Googled a while, and came up short. So I was wondering if you had some words of widom for me on this ? Kind Regards Mark ___ 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] is this a service tracker bug?
Matt, please open a bug against Equinox-Framework. I have reproduced, it appears to be related to lazy activation. If you remove the Eclipse-LazyStart header from Bundle A then it works. This is an interesting corner case we may need to get a clarification from OSGi on. I assume the old content of the bundle will not have access to a BundleContext. What does it mean to get wired to old pending removal content of a bundle that is lazy activated? The classes may be in an invalid state if they cannot have access to a BundleContext. Tom From: BJ Hargrave/Austin/[EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 01/25/2008 12:10 PM Subject:Re: [equinox-dev] is this a service tracker bug? But you should not have to refresh. That is the whole point of importing the package which is exported. So that A' can import it from A which is where B imports it from. I think the IllegalStateException is is a bug in Equinox. -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] office: +1 386 848 1781 mobile: +1 386 848 3788 From: Mark [EMAIL PROTECTED] To: Equinox development mailing list equinox-dev@eclipse.org Date: 2008-01-25 13:06 Subject: Re: [equinox-dev] is this a service tracker bug? I see - It's in an IllegalState until you refresh On 25/01/2008, Mark [EMAIL PROTECTED] wrote: Try adding: Import-Package: bundlea.service to the Bundle A manifest. = I just tried the suggestion above - but it blows up? Framework is launched. idState Bundle 0ACTIVE org.eclipse.osgi_3.3.1.R33x_v20070828 1ACTIVE bundleA_1.0.0 2ACTIVE bundleB_1.0.0 osgi stop 1 removedService osgi update 1 osgi ss Framework is launched. idState Bundle 0ACTIVE org.eclipse.osgi_3.3.1.R33x_v20070828 1INSTALLED bundleA_1.0.0 2ACTIVE bundleB_1.0.0 osgi start 1 org.osgi.framework.BundleException: Exception in bundlea.Activator.start() of bundle bundleA. at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:1018) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:974) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:346) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:260) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:252) at org.eclipse.osgi.framework.internal.core.FrameworkCommandProvider._start(FrameworkCommandProvider.java:260) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.eclipse.osgi.framework.internal.core.FrameworkCommandInterpreter.execute(FrameworkCommandInterpreter.java:150) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.docommand(FrameworkConsole.java:291) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.console(FrameworkConsole.java:276) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.run(FrameworkConsole.java:218) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.IllegalStateException: The state indicates the bundle is resolved at org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureMessage(AbstractBundle.java:1376) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:305) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:260) at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:400) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:111) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:417) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:189) at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java:340) at org.eclipse.osgi.framework.internal.core.SingleSourcePackage.loadClass(SingleSourcePackage.java:37) at
