| Problems moving to latest serverside OSGI code [message #63109] |
Thu, 02 March 2006 18:55  |
Eclipse User |
|
|
|
We have been using the bride.war published in the Incubator page in
mid-January. I wanted to move to the latest code (in CVS HEAD) and have
run into several problems. Before I go into details I would encourage some
process change to have the WAR produced and published by Equinox (in the
build process or ourside of it). I tried to do it manually and found it to
be very error prone and problematic.
Here are the issues I had to resolve
1. An eclipse extension registry change required moving to 3.2M5 plugins.
I replaced existing M4 plug-ins. If there are additional dependent
plug-ins required I did not check for them.
2. There was an undeclared dependency org.eclipse.equinox.servlet.api that
was eventually discovered in config.ini. Without it OSGI failed to start.
It would have helped if this dependency were declared in one of the other
equiniox.server bundles.
Here are the issues I have not been able to resolve:
1. Not all the bundles in the WAR are being discovered. They are in the
WAR but missing from the bundles list when OSGI is up. The are in the
/platform/plugins directory of the deployed WAR and the framework runtime
directory. For example we require EMF and all the EMF bundles were missing
from the list. I added them to the config.ini and they went to resolve
state but I am working with dozens of bundles (and the list is not static)
so this approach won't work.
2. The other bundles that are not missing are in INSTALL state. This
includes our servlet so nothing works.
To simplify the issue, I added a single bundle with no dependencies that
defined a servlet extension and it was also in INSTALL state. As such it
the servlet was not discovered during initialization. I can't account for
the missing ones though.
It would seem that the update configurator is not doing its job correctly.
I suggestions would be welcome.
Finally, I would like to reiterate an process for a regularly updated WAR.
A war file with the name of the CVS tag of the code used to produce it
would be useful so the source code can be related.
Thanks,
Jim D'Anjou
|
|
|
|
|
| Re: Problems moving to latest serverside OSGI code [message #63179 is a reply to message #63109] |
Thu, 02 March 2006 23:23  |
| Eclipse User |
|
|
|
Originally posted by: skaegi.sympatico.ca
Hi Jim,
I hope your problems are resolved in my other reply on this thread.
For questions/comments on builds and equinox.servlet.api bundle
> ...I would encourage some
> process change to have the WAR produced and published by Equinox (in the
> build process or ourside of it). I tried to do it manually and found it to
> be very error prone and problematic.
There was a recent thread on the dev list that briefly mentioned this and
the server-side incubator is working towards integrating with the main
equinox nightly build.
Before this is done though I'd like to do a final transition to bundle names
and package names that take in to account what is and isn't API.
This move and reorganization of the code should happen within the next week
or so with more details to follow. (see bug 128059)
My main motivation here is I don't want to do build integration twice,
especially since I'll probably need a bit of help.
>
> There was an undeclared dependency org.eclipse.equinox.servlet.api that
> was eventually discovered in config.ini. Without it OSGI failed to start.
> It would have helped if this dependency were declared in one of the other
> equiniox.server bundles.
The use of the equinox.servlet.api in config.ini is a bit of a short-term
band-aid. I'm working on something more flexible to provide both 2.3 and
when applicable 2.4 support. So... this bundle will be replaced with
something dynamically generated (either system fragments or dummy bundles
that just do the servlet exports)
Using package imports instead of a bundle dependency lets this change happen
seamlessly.
At dev time in the IDE though the equinox.servlet.api is still needed.
I've had a few issues in M5 with javax.servlet packages resolving to the
x-internal tomcat copy of servlet.jar. I'd recommend that
org.eclipse.equinox.servlet.api be "installed" instead of just in your
workspace.
Hope some of this helps clarify things a bit.
-Simon
"Jim D'Anjou" <danjou@us.ibm.com> wrote in message
news:b3a1b95fad09f453be41dc3d92499300$1@www.eclipse.org...
> We have been using the bride.war published in the Incubator page in
> mid-January. I wanted to move to the latest code (in CVS HEAD) and have
> run into several problems. Before I go into details I would encourage some
> process change to have the WAR produced and published by Equinox (in the
> build process or ourside of it). I tried to do it manually and found it to
> be very error prone and problematic.
>
> Here are the issues I had to resolve
>
> 1. An eclipse extension registry change required moving to 3.2M5 plugins.
> I replaced existing M4 plug-ins. If there are additional dependent
> plug-ins required I did not check for them.
> 2. There was an undeclared dependency org.eclipse.equinox.servlet.api that
> was eventually discovered in config.ini. Without it OSGI failed to start.
> It would have helped if this dependency were declared in one of the other
> equiniox.server bundles.
>
> Here are the issues I have not been able to resolve:
>
> 1. Not all the bundles in the WAR are being discovered. They are in the
> WAR but missing from the bundles list when OSGI is up. The are in the
> /platform/plugins directory of the deployed WAR and the framework runtime
> directory. For example we require EMF and all the EMF bundles were missing
> from the list. I added them to the config.ini and they went to resolve
> state but I am working with dozens of bundles (and the list is not static)
> so this approach won't work.
>
> 2. The other bundles that are not missing are in INSTALL state. This
> includes our servlet so nothing works.
>
> To simplify the issue, I added a single bundle with no dependencies that
> defined a servlet extension and it was also in INSTALL state. As such it
> the servlet was not discovered during initialization. I can't account for
> the missing ones though.
>
> It would seem that the update configurator is not doing its job correctly.
>
> I suggestions would be welcome.
>
> Finally, I would like to reiterate an process for a regularly updated WAR.
> A war file with the name of the CVS tag of the code used to produce it
> would be useful so the source code can be related.
>
> Thanks,
>
> Jim D'Anjou
>
>
>
>
>
>
|
|
|
Powered by
FUDForum. Page generated in 0.05161 seconds
Home