Home » Eclipse Projects » Eclipse Platform » language packs for 3.2 don't get resolved right in 3.3
| language packs for 3.2 don't get resolved right in 3.3 [message #329110] |
Thu, 12 June 2008 18:05  |
Eclipse User |
|
|
|
We're using eclipse 3.3 as the base of my rcp application. We modified
the manifest files that needed modification to run with in eclispe 3.3.
The issue we're facing, is when the application is first launched (the
directory ./configuration/org.eclipse.osgi does not exist), some
fragments never reach the resolved state, and are stuck in installed
state. If you close the application and restart, then they are all
resolved.
This affects us because our application downloads new features on first
use, and when refreshing the current configuration, OSGI thinks we have
downloaded updates for equinox and it shuts down our application. If
these fragments would show up as resolved on first use, then our issue
would go away.
Here is an example of one group causing us issues:
2 ACTIVE org.eclipse.update.configurator_3.2.101.R33x_v20070810
Fragments=125
123 INSTALLED org.eclipse.update.configurator.nl1_3.2.1.v200609270227
124 INSTALLED org.eclipse.update.configurator.nl2a_3.2.1.v200609270227
125 RESOLVED org.eclipse.update.configurator.nl2_3.2.1.v200609270227
Master=2
Sometimes its only one of the three staying in the installed state. The
only consistent property, is that at least one will be in the installed
state on first use of the application. Any theories would be much
appreciated!!
Thanks,
Alej.
|
|
|
| Re: language packs for 3.2 don't get resolved right in 3.3 [message #329112 is a reply to message #329110] |
Thu, 12 June 2008 18:42  |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Alejandro,
Comments below.
Alejandro Bascuas wrote:
> We're using eclipse 3.3 as the base of my rcp application. We modified
> the manifest files that needed modification to run with in eclispe 3.3.
>
> The issue we're facing, is when the application is first launched (the
> directory ./configuration/org.eclipse.osgi does not exist), some
> fragments never reach the resolved state, and are stuck in installed
> state. If you close the application and restart, then they are all
> resolved.
Have you tried the -debug flag to get extra information? Using -clean
-debug should try it all again and give details.
>
> This affects us because our application downloads new features on
> first use, and when refreshing the current configuration, OSGI thinks
> we have downloaded updates for equinox and it shuts down our
> application. If these fragments would show up as resolved on first
> use, then our issue would go away.
>
> Here is an example of one group causing us issues:
>
> 2 ACTIVE
> org.eclipse.update.configurator_3.2.101.R33x_v20070810
> Fragments=125
>
> 123 INSTALLED
> org.eclipse.update.configurator.nl1_3.2.1.v200609270227
> 124 INSTALLED
> org.eclipse.update.configurator.nl2a_3.2.1.v200609270227
> 125 RESOLVED
> org.eclipse.update.configurator.nl2_3.2.1.v200609270227
> Master=2
>
>
> Sometimes its only one of the three staying in the installed state.
> The only consistent property, is that at least one will be in the
> installed state on first use of the application. Any theories would be
> much appreciated!!
>
> Thanks,
>
> Alej.
|
|
|
| Re: language packs for 3.2 don't get resolved right in 3.3 [message #329114 is a reply to message #329112] |
Thu, 12 June 2008 19:12 |
| Eclipse User |
|
|
|
Ed,
Running -debug didn't produce anything to indicate what the problem is.
I then copied the .options file from org.eclipse.osgi and started
playing around with enabling some of the debuggers.
In this run, only 1 of the 3 are not resolved:
202 RESOLVED org.eclipse.update.configurator.nl1_3.2.1.v200609270227
Master=2
203 INSTALLED org.eclipse.update.configurator.nl2a_3.2.1.v200609270227
204 RESOLVED org.eclipse.update.configurator.nl2_3.2.1.v200609270227
Master=2
And searching through the debug:
SLL: starting bundle 202
Trying to resume bundle
update@plugins/org.eclipse.update.configurator.nl1_3.2.1
..v200609270227.jar [202]
SLL: Bundle Startlevel set to 4
SLL: bundle active=false; newSL = 4; activeSL = 6
SLL: starting bundle 203
Trying to resume bundle
update@plugins/org.eclipse.update.configurator.nl2a_3.2.
1.v200609270227.jar [203]
SLL: Bundle Startlevel set to 4
SLL: bundle active=false; newSL = 4; activeSL = 6
SLL: starting bundle 204
Trying to resume bundle
update@plugins/org.eclipse.update.configurator.nl2_3.2.1
..v200609270227.jar [204]
SLL: Bundle Startlevel set to 4
SLL: bundle active=false; newSL = 4; activeSL = 6
Now, I have no idea what any of that means. I just noticed that all
three are set to the same start level. I'll be happy to provide any
information from the console if you tell me what options to turn on.
Thanks,
Alej.
Ed Merks wrote:
> Alejandro,
>
> Comments below.
>
>
> Alejandro Bascuas wrote:
>> We're using eclipse 3.3 as the base of my rcp application. We modified
>> the manifest files that needed modification to run with in eclispe 3.3.
>>
>> The issue we're facing, is when the application is first launched (the
>> directory ./configuration/org.eclipse.osgi does not exist), some
>> fragments never reach the resolved state, and are stuck in installed
>> state. If you close the application and restart, then they are all
>> resolved.
> Have you tried the -debug flag to get extra information? Using -clean
> -debug should try it all again and give details.
>>
>> This affects us because our application downloads new features on
>> first use, and when refreshing the current configuration, OSGI thinks
>> we have downloaded updates for equinox and it shuts down our
>> application. If these fragments would show up as resolved on first
>> use, then our issue would go away.
>>
>> Here is an example of one group causing us issues:
>>
>> 2 ACTIVE
>> org.eclipse.update.configurator_3.2.101.R33x_v20070810
>> Fragments=125
>>
>> 123 INSTALLED
>> org.eclipse.update.configurator.nl1_3.2.1.v200609270227
>> 124 INSTALLED
>> org.eclipse.update.configurator.nl2a_3.2.1.v200609270227
>> 125 RESOLVED
>> org.eclipse.update.configurator.nl2_3.2.1.v200609270227
>> Master=2
>>
>>
>> Sometimes its only one of the three staying in the installed state.
>> The only consistent property, is that at least one will be in the
>> installed state on first use of the application. Any theories would be
>> much appreciated!!
>>
>> Thanks,
>>
>> Alej.
|
|
|
| Re: language packs for 3.2 don't get resolved right in 3.3 [message #329115 is a reply to message #329114] |
Thu, 12 June 2008 21:36 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Alej,
Are you looking in the <workspace>/.metadata/.log? I seem to recall a
planet Eclipse blog recently that describe some way of asking a bundle
to diagnose it status, but I don't recall which one or how. Something
in the PDE perspective I think...
Alejandro Bascuas wrote:
> Ed,
>
> Running -debug didn't produce anything to indicate what the problem
> is. I then copied the .options file from org.eclipse.osgi and started
> playing around with enabling some of the debuggers.
>
> In this run, only 1 of the 3 are not resolved:
>
> 202 RESOLVED
> org.eclipse.update.configurator.nl1_3.2.1.v200609270227
> Master=2
> 203 INSTALLED
> org.eclipse.update.configurator.nl2a_3.2.1.v200609270227
> 204 RESOLVED
> org.eclipse.update.configurator.nl2_3.2.1.v200609270227
> Master=2
>
>
> And searching through the debug:
>
> SLL: starting bundle 202
> Trying to resume bundle
> update@plugins/org.eclipse.update.configurator.nl1_3.2.1
> .v200609270227.jar [202]
> SLL: Bundle Startlevel set to 4
> SLL: bundle active=false; newSL = 4; activeSL = 6
> SLL: starting bundle 203
> Trying to resume bundle
> update@plugins/org.eclipse.update.configurator.nl2a_3.2.
> 1.v200609270227.jar [203]
> SLL: Bundle Startlevel set to 4
> SLL: bundle active=false; newSL = 4; activeSL = 6
> SLL: starting bundle 204
> Trying to resume bundle
> update@plugins/org.eclipse.update.configurator.nl2_3.2.1
> .v200609270227.jar [204]
> SLL: Bundle Startlevel set to 4
> SLL: bundle active=false; newSL = 4; activeSL = 6
>
> Now, I have no idea what any of that means. I just noticed that all
> three are set to the same start level. I'll be happy to provide any
> information from the console if you tell me what options to turn on.
>
> Thanks,
>
> Alej.
>
> Ed Merks wrote:
>> Alejandro,
>>
>> Comments below.
>>
>>
>> Alejandro Bascuas wrote:
>>> We're using eclipse 3.3 as the base of my rcp application. We
>>> modified the manifest files that needed modification to run with in
>>> eclispe 3.3.
>>>
>>> The issue we're facing, is when the application is first launched
>>> (the directory ./configuration/org.eclipse.osgi does not exist),
>>> some fragments never reach the resolved state, and are stuck in
>>> installed state. If you close the application and restart, then they
>>> are all resolved.
>> Have you tried the -debug flag to get extra information? Using
>> -clean -debug should try it all again and give details.
>>>
>>> This affects us because our application downloads new features on
>>> first use, and when refreshing the current configuration, OSGI
>>> thinks we have downloaded updates for equinox and it shuts down our
>>> application. If these fragments would show up as resolved on first
>>> use, then our issue would go away.
>>>
>>> Here is an example of one group causing us issues:
>>>
>>> 2 ACTIVE
>>> org.eclipse.update.configurator_3.2.101.R33x_v20070810
>>> Fragments=125
>>>
>>> 123 INSTALLED
>>> org.eclipse.update.configurator.nl1_3.2.1.v200609270227
>>> 124 INSTALLED
>>> org.eclipse.update.configurator.nl2a_3.2.1.v200609270227
>>> 125 RESOLVED
>>> org.eclipse.update.configurator.nl2_3.2.1.v200609270227
>>> Master=2
>>>
>>>
>>> Sometimes its only one of the three staying in the installed state.
>>> The only consistent property, is that at least one will be in the
>>> installed state on first use of the application. Any theories would
>>> be much appreciated!!
>>>
>>> Thanks,
>>>
>>> Alej.
|
|
|
| Re: language packs for 3.2 don't get resolved right in 3.3 [message #329133 is a reply to message #329115] |
Fri, 13 June 2008 10:45 |
| Eclipse User |
|
|
|
From the .log file:
!SESSION 2008-06-12 18:01:54.806
-----------------------------------------------
eclipse.buildId=unknown
java.fullversion=J2RE 1.5.0 IBM J9 2.3 Windows XP x86-32
j9vmwi3223-20080315 (JIT enabled)
J9VM - 20080314_17962_lHdSMr
JIT - 20080130_0718ifx2_r8
GC - 200802_08
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US
Framework arguments: -launchWizard
com.ibm.bbp.desktop.ui.serverapplicationinstall
Command-line arguments: -os win32 -ws win32 -arch x86 -data
@user.home/IBM/RCP/b Administration -launchWizard
com.ibm.bbp.desktop.ui.serverapplicationinstall -clean -console -debug
!ENTRY org.eclipse.update.configurator 4 0 2008-06-12 18:01:58.082
!MESSAGE
!STACK 0
org.osgi.framework.BundleException: Cannot attach fragment bundle
"org.eclipse.update.configurator.nl2" to resolved host
"org.eclipse.update.configurator". Try refreshing the host bundle.
at
org.eclipse.osgi.framework.internal.core.BundleHost.attachFr agment(BundleHost.java:575)
at
org.eclipse.osgi.framework.internal.core.BundleFragment.addH ost(BundleFragment.java:298)
at
org.eclipse.osgi.framework.internal.core.PackageAdminImpl.se tResolved(PackageAdminImpl.java:332)
at
org.eclipse.osgi.framework.internal.core.PackageAdminImpl.ap plyDeltas(PackageAdminImpl.java:347)
at
org.eclipse.osgi.framework.internal.core.PackageAdminImpl.pr ocessDelta(PackageAdminImpl.java:424)
at
org.eclipse.osgi.framework.internal.core.PackageAdminImpl.do ResolveBundles(PackageAdminImpl.java:221)
at
org.eclipse.osgi.framework.internal.core.PackageAdminImpl$1. run(PackageAdminImpl.java:164)
at java.lang.Thread.run(Thread.java:810)
!ENTRY org.eclipse.equinox.common 4 0 2008-06-12 18:01:58.102
!MESSAGE
!STACK 0
org.osgi.framework.BundleException: Cannot attach fragment bundle
"org.eclipse.equinox.common.nl2" to resolved host
"org.eclipse.equinox.common". Try refreshing the host bundle.
at
org.eclipse.osgi.framework.internal.core.BundleHost.attachFr agment(BundleHost.java:575)
at
org.eclipse.osgi.framework.internal.core.BundleFragment.addH ost(BundleFragment.java:298)
at
org.eclipse.osgi.framework.internal.core.PackageAdminImpl.se tResolved(PackageAdminImpl.java:332)
at
org.eclipse.osgi.framework.internal.core.PackageAdminImpl.ap plyDeltas(PackageAdminImpl.java:347)
at
org.eclipse.osgi.framework.internal.core.PackageAdminImpl.pr ocessDelta(PackageAdminImpl.java:424)
at
org.eclipse.osgi.framework.internal.core.PackageAdminImpl.do ResolveBundles(PackageAdminImpl.java:221)
at
org.eclipse.osgi.framework.internal.core.PackageAdminImpl$1. run(PackageAdminImpl.java:164)
at java.lang.Thread.run(Thread.java:810)
!ENTRY org.eclipse.equinox.common 4 0 2008-06-12 18:01:58.102
!MESSAGE
!STACK 0
org.osgi.framework.BundleException: Cannot attach fragment bundle
"org.eclipse.equinox.common.nl2" to resolved host
"org.eclipse.equinox.common". Try refreshing the host bundle.
at
org.eclipse.osgi.framework.internal.core.BundleHost.attachFr agment(BundleHost.java:575)
at
org.eclipse.osgi.framework.internal.core.BundleFragment.addH ost(BundleFragment.java:298)
at
org.eclipse.osgi.framework.internal.core.PackageAdminImpl.se tResolved(PackageAdminImpl.java:332)
at
org.eclipse.osgi.framework.internal.core.PackageAdminImpl.ap plyDeltas(PackageAdminImpl.java:347)
at
org.eclipse.osgi.framework.internal.core.PackageAdminImpl.pr ocessDelta(PackageAdminImpl.java:424)
at
org.eclipse.osgi.framework.internal.core.PackageAdminImpl.do ResolveBundles(PackageAdminImpl.java:221)
at
org.eclipse.osgi.framework.internal.core.PackageAdminImpl$1. run(PackageAdminImpl.java:164)
at java.lang.Thread.run(Thread.java:810)
!ENTRY org.eclipse.osgi 2 0 2008-06-12 18:01:59.604
!MESSAGE The following is a complete list of bundles which are not
resolved, see the prior log entry for the root cause if it exists:
!SUBENTRY 1 org.eclipse.osgi 2 0 2008-06-12 18:01:59.604
!MESSAGE Bundle
update@plugins/org.eclipse.equinox.common.nl1_3.2.0.v200609270227a.jar
[113] was not resolved.
!SUBENTRY 1 org.eclipse.osgi 2 0 2008-06-12 18:01:59.604
!MESSAGE Bundle
update@plugins/org.eclipse.equinox.common.nl2a_3.2.0.v200609270227a.jar
[114] was not resolved.
!SUBENTRY 1 org.eclipse.osgi 2 0 2008-06-12 18:01:59.604
!MESSAGE Bundle
update@plugins /org.eclipse.update.configurator.nl2a_3.2.1.v200609270227.ja r
[203] was not resolved.
Alej.
Ed Merks wrote:
> Alej,
>
> Are you looking in the <workspace>/.metadata/.log? I seem to recall a
> planet Eclipse blog recently that describe some way of asking a bundle
> to diagnose it status, but I don't recall which one or how. Something
> in the PDE perspective I think...
>
>
> Alejandro Bascuas wrote:
>> Ed,
>>
>> Running -debug didn't produce anything to indicate what the problem
>> is. I then copied the .options file from org.eclipse.osgi and started
>> playing around with enabling some of the debuggers.
>>
>> In this run, only 1 of the 3 are not resolved:
>>
>> 202 RESOLVED
>> org.eclipse.update.configurator.nl1_3.2.1.v200609270227
>> Master=2
>> 203 INSTALLED
>> org.eclipse.update.configurator.nl2a_3.2.1.v200609270227
>> 204 RESOLVED
>> org.eclipse.update.configurator.nl2_3.2.1.v200609270227
>> Master=2
>>
>>
>> And searching through the debug:
>>
>> SLL: starting bundle 202
>> Trying to resume bundle
>> update@plugins/org.eclipse.update.configurator.nl1_3.2.1
>> .v200609270227.jar [202]
>> SLL: Bundle Startlevel set to 4
>> SLL: bundle active=false; newSL = 4; activeSL = 6
>> SLL: starting bundle 203
>> Trying to resume bundle
>> update@plugins/org.eclipse.update.configurator.nl2a_3.2.
>> 1.v200609270227.jar [203]
>> SLL: Bundle Startlevel set to 4
>> SLL: bundle active=false; newSL = 4; activeSL = 6
>> SLL: starting bundle 204
>> Trying to resume bundle
>> update@plugins/org.eclipse.update.configurator.nl2_3.2.1
>> .v200609270227.jar [204]
>> SLL: Bundle Startlevel set to 4
>> SLL: bundle active=false; newSL = 4; activeSL = 6
>>
>> Now, I have no idea what any of that means. I just noticed that all
>> three are set to the same start level. I'll be happy to provide any
>> information from the console if you tell me what options to turn on.
>>
>> Thanks,
>>
>> Alej.
>>
>> Ed Merks wrote:
>>> Alejandro,
>>>
>>> Comments below.
>>>
>>>
>>> Alejandro Bascuas wrote:
>>>> We're using eclipse 3.3 as the base of my rcp application. We
>>>> modified the manifest files that needed modification to run with in
>>>> eclispe 3.3.
>>>>
>>>> The issue we're facing, is when the application is first launched
>>>> (the directory ./configuration/org.eclipse.osgi does not exist),
>>>> some fragments never reach the resolved state, and are stuck in
>>>> installed state. If you close the application and restart, then they
>>>> are all resolved.
>>> Have you tried the -debug flag to get extra information? Using
>>> -clean -debug should try it all again and give details.
>>>>
>>>> This affects us because our application downloads new features on
>>>> first use, and when refreshing the current configuration, OSGI
>>>> thinks we have downloaded updates for equinox and it shuts down our
>>>> application. If these fragments would show up as resolved on first
>>>> use, then our issue would go away.
>>>>
>>>> Here is an example of one group causing us issues:
>>>>
>>>> 2 ACTIVE
>>>> org.eclipse.update.configurator_3.2.101.R33x_v20070810
>>>> Fragments=125
>>>>
>>>> 123 INSTALLED
>>>> org.eclipse.update.configurator.nl1_3.2.1.v200609270227
>>>> 124 INSTALLED
>>>> org.eclipse.update.configurator.nl2a_3.2.1.v200609270227
>>>> 125 RESOLVED
>>>> org.eclipse.update.configurator.nl2_3.2.1.v200609270227
>>>> Master=2
>>>>
>>>>
>>>> Sometimes its only one of the three staying in the installed state.
>>>> The only consistent property, is that at least one will be in the
>>>> installed state on first use of the application. Any theories would
>>>> be much appreciated!!
>>>>
>>>> Thanks,
>>>>
>>>> Alej.
|
|
|
Goto Forum:
Current Time: Wed May 28 19:57:25 EDT 2025
Powered by FUDForum. Page generated in 0.04391 seconds |
Home