Hi,
After updating to 3.4.1 I had some issues with my test cases for
Equinox Aspects. The reason was, that the latest version of the system
bundle now defines Java 5 as the first execution environment:
Bundle-RequiredExecutionEnvironment: J2SE-1.5,OSGi/Minimum-1.1
Is this by intention? If
Hi All,
I want to use Jetty servlet container to host my servlets within OSGi,
however, the equinox.http.jetty bundle seems to start jetty by default on port
80, or the port specified by the org.osgi.service.http.port property in
config.ini. However I want to programmatically start the
Hi Heiko,
The reason this was added was to avoid compilation errors when importing
org.eclipse.osgi into your workspace as source from the target SDK. The
org.eclipse.osgi project supports the OSGi minimum 1.1 execution
environment but will make use of additional classes from J2SE 1.4 and 1.5
You can disable the autostarting of the deafult instance by setting the
framework property:
org.eclipse.equinox.http.jetty.autostart=false
-Simon
|
| From: |
|
I believe there is a property we can put in the build.properties to
tell PDE which EE to use for compilation purposes. This seems like the
safer and more explicit path regardless of any issues Heiko may be
seeing.
Jeff
Thomas Watson wrote:
Hi Heiko,
The reason this was added was to
We use those properties in the build.properties file in CVS to setup our
advanced classpath during the real build. And besides, the
build.properties from the CVS project is not the same as the one used by
PDE when you import as source. In this case PDE generates one for you
based on the
sigh. is another option to include the build.properties in the source
and get PDE to use it?
I am more curious than expecting a change here. I agree that it is
unusual that the BREE content/ordering is causing an issue...
Jeff
Thomas Watson wrote:
We use those properties in the
I would suggest trying 3.4M7 where that bug was first fixed, or just move
up to 3.4.
Or if there are other problems upgrading, try at least taking
org.eclipse.update.core from 3.4
-Andrew
Janet Dmitrovich [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
10/09/2008 05:29 PM
Please respond to
Hi,
Well, I'm about to throw in the towel, regarding BSF; I think I'll move to
javax.scripting and see where that leads (which is a bit unwieldy, I know)...
I've tried bsfManager.setClassPath() -- that doesn't work;
I've tried bsfManager.setClassLoader() with just about every class loader
I ran jarsigner -verify against the jars
first after normalize and sign, all the jars came back jar verified
then packed the jars ( pack200 )
Then installed ( and so unpacked )
on a number of these I get the error jarsigner:
java.lang.SecurityException: SHA1 digest error for ..class
Does
10 matches
Mail list logo
