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
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
Also, when we started packing we have had notices memory leakage problems
when we were using pack200 through the Java API.
|
| From: |
|
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
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
1
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
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
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
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.
-
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
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
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'
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
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
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
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
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
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
18 matches
Mail list logo
