I tried running both Mandrel:
./mvnw package -Pnative -Dquarkus.native.container-build=true -Dquarkus.native.builder-image=quay.io/quarkus/ubi-quarkus-mandrel:20.3.2.0-Final-java11
and GraalVM version:
./mvnw package -Pnative -Dquarkus.native.container-build=true
but they just get stuck at building, I have the latest Docker for M1, this is a sample from mandrel on which it just stays there using 300% cpu:
[INFO] [io.quarkus.deployment.pkg.steps.NativeImageBuildStep] docker run -v lambda-0.0.1-SNAPSHOT-native-image-source-jar:/project:z --env LANG=C --rm quay.io/quarkus/ubi-quarkus-mandrel:20.3.2.0-Final-java11 -J-Djava.util.logging.manager=org.jboss.logmanager.LogManager -J-Dcom.mysql.cj.disableAbandonedConnectionCleanup=true -J-DCoordinatorEnvironmentBean.transactionStatusManagerEnable=false -J-Dsun.nio.ch.maxUpdateArraySize=100 -J-Dcom.sun.xml.bind.v2.bytecode.ClassTailor.noOptimize=true -J-Dio.netty.leakDetection.level=DISABLED -J-Dio.netty.allocator.maxOrder=1 -J-Duser.language=en -J-Dfile.encoding=UTF-8 --report-unsupported-elements-at-runtime --enable-all-security-services --allow-incomplete-classpath -H:DynamicProxyConfigurationFiles=dynamic-proxies.json -H:ResourceConfigurationFiles=resources-config.json -H:ReflectionConfigurationFiles=reflection-config.json --initialize-at-run-time=com.common.utils -H:+ReportExceptionStackTraces --initialize-at-build-time= -H:InitialCollectionPolicy=com.oracle.svm.core.genscavenge.CollectionPolicy\$BySpaceAndTime -H:+JNI -jar lambda-0.0.1-SNAPSHOT-runner.jar -H:FallbackThreshold=0 -H:+ReportExceptionStackTraces -H:+AddAllCharsets -H:EnableURLProtocols=http,https --enable-all-security-services -H:-UseServiceLoaderFeature -H:+StackTrace lambda-0.0.1-SNAPSHOT-runner
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
[ithaca-creditcards-service-lambda-0.0.1-SNAPSHOT-runner:71] classlist: 75,914.69 ms, 1.06 GB
[ithaca-creditcards-service-lambda-0.0.1-SNAPSHOT-runner:71] (cap): 5,804.38 ms, 1.06 GB
[ithaca-creditcards-service-lambda-0.0.1-SNAPSHOT-runner:71] setup: 18,307.33 ms, 1.06 GB
02:57:58,598 INFO [org.hib.val.int.uti.Version] HV000001: Hibernate Validator 6.1.6.Final
02:57:59,639 INFO [org.hib.Version] HHH000412: Hibernate ORM core version 5.4.24.Final
02:57:59,679 INFO [org.hib.ann.com.Version] HCANN000001: Hibernate Commons Annotations {5.1.2.Final}
02:57:59,894 INFO [org.hib.dia.Dialect] HHH000400: Using dialect: org.hibernate.dialect.MySQL8Dialect
02:58:02,539 INFO [org.hib.orm.beans] HHH10005002: No explicit CDI BeanManager reference was passed to Hibernate, but CDI is available on the Hibernate ClassLoader.
First create docker file for GraalVM image:
FROM ghcr.io/graalvm/graalvm-ce:22 as build
RUN gu install native-image
WORKDIR /project
VOLUME ["/project"]
ENTRYPOINT ["native-image"]
Save this file as Dockerfile.graalvm. Then build the GraalVM image using it
docker build -f src/main/docker/Dockerfile.graalvm -t graalvm .
Now you have GraalVM image and can build quarkus Linux image
./mvnw package -Pnative -Dquarkus.native.container-build=true -Dquarkus.native.builder-image=graalvm
The runner, that has been created is 64-bit ARM aarch64 executable and can be used to create a docker container
docker build -f src/main/docker/Dockerfile.native -t quarkus/your-app .
And finally run it
docker run --rm -p 8080:8080 quarkus/your-app
Related
My Spring Cloud 2022.0.0-M5 + Spring Boot 3.0.0-M5 webmvc application works as a normal JVM application but fails when compiled to native:
c.e.m.w.proxy.server.MyServerKt : Starting MyServerKt using Java 17.0.4.1 on acc1dd6cfd4d with PID 1 (/workspace/myserver.MyServerKt started by cnb in /workspace)
c.e.m.w.proxy.server.MyServerKt : The following 1 profile is active: "prod"
o.s.c.c.c.ConfigServerConfigDataLoader : Fetching config from server at : http://configserver:8080
o.s.c.c.c.ConfigServerConfigDataLoader : Located environment: name=application, profiles=[prod], label=null, version=4563ba0531478bdc637b677819dedcebf7bd2bc3, state=null
w.s.c.ServletWebServerApplicationContext : Exception encountered during context initialization - cancelling refresh attempt: org.springframework.context.ApplicationContextException: Unable to start web server
o.s.b.d.LoggingFailureAnalysisReporter :
***************************
APPLICATION FAILED TO START
***************************
Description:
Web application could not be started as there was no org.springframework.boot.web.servlet.server.ServletWebServerFactory bean defined in the context.
Action:
Check your application's dependencies for a supported servlet web server.
Check the configured web application type.
Do you have any idea where should I start investigating?
All I see in the AOT build log that Tomcat is on the classpath:
[creator] Executing native-image -H:+StaticExecutableWithDynamicLibC --enable-url-protocols=http --initialize-at-run-time=io.netty ... -cp ... :/workspace/BOOT-INF/lib/tomcat-embed-core-10.0.23.jar: ...
AOT building environment info:
[creator] Version info: 'GraalVM 22.2.0 Java 17 CE'
[creator] Java version info: '17.0.4.1+1-LTS'
[creator] C compiler: gcc (linux, x86_64, 7.5.0)
I have a Spring Boot application which I'm building and running with Java 10. If I run the app using
java -jar
Everything works fine. The app starts just OK.
But if I put my app inside a Docker container with the exactly same Java version, my app throws this exception:
Caused by: java.lang.NoClassDefFoundError: Could not initialize class org.jgroups.logging.Slf4jLogImpl
at org.jgroups.logging.LogFactory.getLog(LogFactory.java:101)
at org.jgroups.conf.XmlConfigurator.<clinit>(XmlConfigurator.java:33)
at org.jgroups.conf.ConfiguratorFactory.getStackConfigurator(ConfiguratorFactory.java:62)
at org.jgroups.JChannel.<init>(JChannel.java:122)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:591)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannel(JGroupsTransport.java:405)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:389)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at org.infinispan.commons.util.SecurityActions.lambda$invokeAccessibly$0(SecurityActions.java:79)
... 104 common frames omitted
I'm using this version of Java:
java version "10.0.2" 2018-07-17
Java(TM) SE Runtime Environment 18.3 (build 10.0.2+13)
Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10.0.2+13, mixed mode)
Docker version is:
Client:
Version: 18.06.1-ce
API version: 1.38
Go version: go1.10.3
Git commit: e68fc7a
Built: Tue Aug 21 17:21:31 2018
OS/Arch: darwin/amd64
Experimental: false
Server:
Engine:
Version: 18.06.1-ce
API version: 1.38 (minimum version 1.12)
Go version: go1.10.3
Git commit: e68fc7a
Built: Tue Aug 21 17:29:02 2018
OS/Arch: linux/amd64
Experimental: true
My Docker is using an Alpine base image alpine:latest. I'm installing java in my container from this link:
curl -jksSLH "Cookie: oraclelicense=accept-securebackup-cookie" -o /tmp/java.tar.gz \
http://download.oracle.com/otn-pub/java/jdk/10.0.2+13/19aef61b38124481863b1413dce1855f/jdk-10.0.2_linux-x64_bin.tar.gz
I'm really confused because from outside a docker container my app works fine, but inside a docker container it doesn't. Either case I'm using the same Java version.
UPDATE
We tried Oracle JDK and OpenJDK, same behavior
UPDATE 2
We even tried java -jar from inside the container, no luck
TL;DR
There are three options to resolve.
Upgrade to version 4.0.16 of JGroups, currently in SNAPSHOT. Edit: Now released here.
Make sure java properties for "user.language" and "user.country" are set.
Force JDKLogImpl with -Djgroups.use.jdk_logger=true. (mentioned by Perimosh)
Explanation
Ran into this issue in the following scenario.
Apache Camel + JGroups worked fine in a local environment. Deployed it elsewhere in a Docker instance, where we got the following stacktrace:
2018-11-19 13:38:03.063 INFO 582 --- [ main] o.a.camel.spring.boot.RoutesCollector : Loading additional Camel XML routes from: classpath:camel/*.xml
2018-11-19 13:38:03.064 INFO 582 --- [ main] o.a.camel.spring.boot.RoutesCollector : Loading additional Camel XML rests from: classpath:camel-rest/*.xml
2018-11-19 13:38:03.107 INFO 582 --- [ main] o.a.camel.spring.SpringCamelContext : Apache Camel 2.22.2 (CamelContext: camel-1) is starting
2018-11-19 13:38:03.111 INFO 582 --- [ main] o.a.c.m.ManagedManagementStrategy : JMX is enabled
2018-11-19 13:38:03.480 INFO 582 --- [ main] o.a.camel.spring.SpringCamelContext : StreamCaching is not in use. If using streams then its recommended to enable stream caching. See more details at http://camel.apache.org/stream-caching.html
2018-11-19 13:38:03.597 INFO 582 --- [ main] o.a.camel.spring.SpringCamelContext : Apache Camel 2.22.2 (CamelContext: camel-1) is shutting down
2018-11-19 13:38:03.616 WARN 582 --- [ main] o.a.camel.spring.SpringCamelContext : Error occurred while shutting down service: org.apache.camel.component.jgroups.cluster. JGroupsLockClusterService#10fa5af5. This exception will be ignored.
java.lang.NullPointerException: null
at org.apache.camel.component.jgroups.cluster.JGroupsLockClusterView.doStop(JGroupsLockClusterView.java:109)
at org.apache.camel.support.ServiceSupport.stop(ServiceSupport.java:102)
at org.apache.camel.impl.cluster.AbstractCamelClusterService.lambda$doStop$2(AbstractCamelClusterService.java:134)
at org.apache.camel.util.concurrent.LockHelper.doWithReadLockT(LockHelper.java:54)
at org.apache.camel.impl.cluster.AbstractCamelClusterService.doStop(AbstractCamelClusterService.java:130)
at org.apache.camel.support.ServiceSupport.stop(ServiceSupport.java:102)
at org.apache.camel.util.ServiceHelper.stopService(ServiceHelper.java:142)
at org.apache.camel.util.ServiceHelper.stopAndShutdownService(ServiceHelper.java:205)
at org.apache.camel.impl.DefaultCamelContext.shutdownServices(DefaultCamelContext.java:3663)
at org.apache.camel.impl.DefaultCamelContext.shutdownServices(DefaultCamelContext.java:3688)
at org.apache.camel.impl.DefaultCamelContext.shutdownServices(DefaultCamelContext.java:3676)
at org.apache.camel.impl.DefaultCamelContext.doStop(DefaultCamelContext.java:3567)
at org.apache.camel.support.ServiceSupport.stop(ServiceSupport.java:102)
at org.apache.camel.impl.DefaultCamelContext.stop(DefaultCamelContext.java:3220)
at org.apache.camel.spring.SpringCamelContext.stop(SpringCamelContext.java:148)
...
2018-11-19 13:38:03.679 INFO 582 --- [ main] o.a.camel.spring.SpringCamelContext : Apache Camel 2.22.2 (CamelContext: camel-1) uptime 0.570 seconds
2018-11-19 13:38:03.680 INFO 582 --- [ main] o.a.camel.spring.SpringCamelContext : Apache Camel 2.22.2 (CamelContext: camel-1) is shutdown in 0.082 seconds
2018-11-19 13:38:03.716 INFO 582 --- [ main] org.mongodb.driver.connection : Closed connection [connectionId{localValue:2, serverValue:2}] to localhost:43115 because the pool has been closed.
As you can see, Apache Camel attempts to start, but never does and ends up shutting down. Thus, JGroups gets a NPE because it expects Camel to be up.
After debugging the code, it appeared that there was an exception being thrown during the Camel start up process which was getting eaten.
From there, discovered that the creation of an instance of Slf4jLogImpl in org.jgroups.logging.LogFactory#getLog(java.lang.Class<?>) (new Slf4jLogImpl(clazz)) was a problem Method threw 'java.lang.ExceptionInInitializerError' exception.:
java.lang.NullPointerException: null
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at org.jgroups.logging.LogFactory.getLog(LogFactory.java:101)
at org.jgroups.conf.XmlConfigurator.<clinit>(XmlConfigurator.java:33)
at org.jgroups.conf.ConfiguratorFactory.getXmlConfigurator(ConfiguratorFactory.java:210)
at org.jgroups.conf.ConfiguratorFactory.getStackConfigurator(ConfiguratorFactory.java:91)
at org.jgroups.JChannel.<init>(JChannel.java:130)
...
Running (new Slf4jLogImpl(clazz)) the second time onward in the debugger results in the following stacktrace that mirrors the original posted issue:
java.lang.NoClassDefFoundError: Could not initialize class org.jgroups.logging.Slf4jLogImpl
at org.jgroups.logging.LogFactory.getLog(LogFactory.java:101)
at org.jgroups.conf.XmlConfigurator.<clinit>(XmlConfigurator.java:33)
at org.jgroups.conf.ConfiguratorFactory.getXmlConfigurator(ConfiguratorFactory.java:210)
at org.jgroups.conf.ConfiguratorFactory.getStackConfigurator(ConfiguratorFactory.java:91)
at org.jgroups.JChannel.<init>(JChannel.java:130)
This difference in results is due to the class loader caching the result of the Class.forName() call previously to determine that the class definition was not found.
Finally, we tracked the previous NPE to be thrown from java.util.Locale#Locale(java.lang.String, java.lang.String, java.lang.String), since country was null. This is because JGroup's org.jgroups.logging.Slf4jLogImpl is definine a LOCALE field using java properties for "user.language" and "user.country". The former was not set in our docker instance, so Locale.java threw the NPE. Adding both of these java properties should fix this issue. Alternatively you can force using the JDKLogImpl so that the Slf4jLogImpl is never attempted to be instantiated. This was mentioned in the previous answer, by passing in -Djgroups.use.jdk_logger=true.
Edit: Fixed in the latest version released here.
Now, it looks like this will be fixed in the upcoming JGroup release of 4.0.16.Final (https://github.com/belaban/JGroups/commit/61578c657138f02178c32a564ac9eae7c3976093#diff-93eb0f6a8a4953312098be459bd7ce76). Until then, you can get the snapshot version with the fix at https://repository.jboss.org/nexus/content/repositories/snapshots/org/jgroups/jgroups/4.0.16-SNAPSHOT/.
This is not a real solution, but since it unblocked us, I will share it. Also, maybe somebody can think about the real problem by looking at this workaround. We added this JVM argument to by pass SLF4J for jgroups and use JDKLogImpl
-Djgroups.use.jdk_logger=true
I have the following things setup on my system.
Ubuntu 16.04
Gradle 3.0
Java 1.8.0_91
springBootVersion : 1.4.0.RELEASE
I am running the spring boot application from command line with the following arguments.
gradle -Dserver.port=8090 -Dspring.profiles.active=dev bootRun
following are the logs
Starting a Gradle Daemon, 3 stopped Daemons could not be reused, use --status for details
No active profile set, falling back to default profiles: default
Registering beans for JMX exposure on startup
2016-10-26 18:36:00.463 INFO 27743 --- [ restartedMain] o.s.c.support.DefaultLifecycleProcessor : Starting beans in phase 0
2016-10-26 18:36:00.584 INFO 27743 --- [ restartedMain] s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat started on port(s): 8080 (http)
when i do gradle --status the result is
No Gradle daemons are running.
PID STATUS INFO
26929 STOPPED (client disconnected)
27086 STOPPED (client disconnected)
27202 STOPPED (client disconnected)
27367 STOPPED (client disconnected)
I am not sure what's gone wrong here. I had been able to run this with no issues previously on older versions of spring boot and gradle.
However when i do
java -jar -Dspring.profiles.active=dev -Dserver.port=8090 build/libs/demo-0.0.1-SNAPSHOT.jar
I am able to run the application with desired arguments, on port 8090 and with dev profile.
Try using:
java -Dspring.profiles.active=dev -Dserver.port=8090 -jar build/libs/demo-0.0.1-SNAPSHOT.jar
I wanted to deploy a simple jsp application: I created and copied the myApp.war file to the $JBOSS_HOME/standalone/deployment folder.
Instead of deploying the war file , JBoss created *.war.failed ,
So I thought maybe it's a good idea to restart the jboss to see if it affects the deployment.
In some forums it was suggested to restart the JBoss through : $JBOSS_HOME/bin/jboss-cli.sh
But there was no shutdown or restart command.
While I was trying to restart , I ran the following command :
/usr/local/jboss7/bin/jboss-cli.sh -c ":shutdown(restart=true)"
JBoss stopped working , but it didn't start again.
Now , I want to start it again by :
$JBOSS_HOME/bin/standalone.sh
But it gives me the following exception :
=========================================================================
JBoss Bootstrap Environment
JBOSS_HOME: /usr/local/jboss7
JAVA: /Library/Java/JavaVirtualMachines/jdk1.7.0_71.jdk/Contents/Home/bin/java
JAVA_OPTS: -server -XX:+UseCompressedOops -XX:+TieredCompilation -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -Djboss.server.default.config=standalone.xml
=========================================================================
17:29:43,399 INFO [org.jboss.modules] JBoss Modules version 1.1.1.GA
17:29:43,536 INFO [org.jboss.msc] JBoss MSC version 1.0.2.GA
17:29:43,567 INFO [org.jboss.as] JBAS015899: JBoss AS 7.1.1.Final "Brontes" starting
17:29:43,876 ERROR [org.jboss.as.server] JBAS015956: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:141) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.as.server.ServerService.boot(ServerService.java:266) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:155) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_71]
Caused by: com.ctc.wstx.exc.WstxUnexpectedCharException: Unexpected character '*' (code 42) (expected a name start character)
at [row,col {unknown-source}]: [190,160]
at com.ctc.wstx.sr.StreamScanner.throwUnexpectedChar(StreamScanner.java:639)
at com.ctc.wstx.sr.StreamScanner.parseLocalName(StreamScanner.java:1798)
at com.ctc.wstx.sr.BasicStreamReader.handleNsAttrs(BasicStreamReader.java:2975)
at com.ctc.wstx.sr.BasicStreamReader.handleStartElem(BasicStreamReader.java:2926)
at com.ctc.wstx.sr.BasicStreamReader.nextFromTree(BasicStreamReader.java:2802)
at com.ctc.wstx.sr.BasicStreamReader.next(BasicStreamReader.java:1050)
at com.ctc.wstx.sr.BasicStreamReader.nextTag(BasicStreamReader.java:1125)
at org.jboss.staxmapper.XMLExtendedStreamReaderImpl.nextTag(XMLExtendedStreamReaderImpl.java:152) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
at org.jboss.as.server.deployment.scanner.DeploymentScannerParser_1_1.readElement(DeploymentScannerParser_1_1.java:85)
at org.jboss.as.server.deployment.scanner.DeploymentScannerParser_1_1.readElement(DeploymentScannerParser_1_1.java:28)
at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
at org.jboss.staxmapper.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:69) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
at org.jboss.as.server.parsing.StandaloneXml.parseServerProfile(StandaloneXml.java:894) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.as.server.parsing.StandaloneXml.readServerElement_1_1(StandaloneXml.java:330) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:127) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:100) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.1.0.Final.jar:1.1.0.Final]
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:133) [jboss-as-controller-7.1.1.Final.jar:7.1.1.Final]
... 3 more
17:29:43,882 FATAL [org.jboss.as.server] JBAS015957: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
17:29:43,889 INFO [org.jboss.as] JBAS015950: JBoss AS 7.1.1.Final "Brontes" stopped in 4ms
I searched for the cause of the problem , and I found that probably there's a problem with standalone.xml file.
In /usr/local/jboss7/standalone/configuration/standalone_xml_history I have the following files , but not the standalone.xml
2014xxxx-xxxxxxxx
snapshot
standalone.initial.xml
current
standalone.boot.xml
standalone.last.xml
I'd like to know if I have to rename any of these files to standalone.xml ? (actually I tried renaming standalone.boot.xml to standalone.xml but it didn't work either !) or download a new one ? may I remove these xml files after having the new standalone.xml ?
If JBoss-7 is installed in $JBOSSHOME, the default standalone configuration file is $JBOSS_HOME/standalone/configuration/standalone.xml; $JBOSSHOME/standalone/configuration is the default value of the jboss.server.config.dir property; and running $JBOSSHOME/bin/standalone.sh with no options will start JBoss in standalone mode on Linux/Unix systems.
In order to use a different standalone configuration file it can be renamed to standalone.xml, put in jboss.server.config.dir if it is not already there and standalone.sh run with no options; or its file name can be given to standalone.sh as an argument to its -c option after it is put in jboss.server.config.dir, for example:
$JBoss_home/bin/standalone.sh -c standalone-full.xml
RedHat documentation for this is at https://docs.jboss.org/author/display/AS71/Command+line+parameters
I have had the best success with standalone/configuration/standalone-full.xml since it has the full configuration. It is shipped with JBoss-7. If you don't have it you could download a fresh copy of the distro to get it. What I always do is archive a zip of the distro for recovery in case something gets corrupted or lost in the working copy.
I googled this for hours but I couldn't find anything useful.
I have developed some OSGi bundles and now I want to run them outside of the Eclipse IDE in the equinox container, but it always throws an exception:
!SESSION 2011-01-03 14:26:58.958 -----------------------------------------------
eclipse.buildId=unknown
java.version=1.6.0_20
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=de_CH
Framework arguments: -Dosgi.clean=true -Declipse.ignoreApp=true -Dosgi.noShutdown=true -console;
Command-line arguments: -consoleLog -Dosgi.clean=true -Declipse.ignoreApp=true -Dosgi.noShutdown=true -console;
!ENTRY org.eclipse.osgi 4 0 2011-01-03 14:26:59.567
!MESSAGE Error starting bundle: initial#reference:file:javax.transaction_1.1.1.v201006150915.jar/
!STACK 0
org.osgi.framework.BundleException: A fragment bundle cannot be started: javax.transaction_1.1.1.v201006150915 [49]
at org.eclipse.osgi.framework.internal.core.BundleFragment.startWorker(BundleFragment.java:228)
at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:284)
at org.eclipse.core.runtime.adaptor.EclipseStarter.startBundle(EclipseStarter.java:1133)
at org.eclipse.core.runtime.adaptor.EclipseStarter.startBundles(EclipseStarter.java:1126)
at org.eclipse.core.runtime.adaptor.EclipseStarter.loadBasicBundles(EclipseStarter.java:646)
at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:301)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:175)
at org.eclipse.core.runtime.adaptor.EclipseStarter.main(EclipseStarter.java:150)
init dd core...
!ENTRY org.eclipse.osgi 4 0 2011-01-03 14:26:59.773
!MESSAGE Bundle javax.transaction_1.1.1.v201006150915 [49] is not active.
(the "init dd core..." text comes properly from my project.)
I have the following file structure:
+configuration
+config.ini
+ch.thobens.dd.commands_1.0.0.jar
+ch.thobens.dd.common.items_1.0.0.jar
+ch.thobens.dd.core_1.0.0.jar
+ch.thobens.dd.game_1.0.0.jar
+javax.transaction_1.1.1.v201006150915.jar
+org.eclipse.core.contenttype_3.4.100.v20100505-1235.jar
+org.eclipse.core.jobs_3.5.0.v20100515.jar
+org.eclipse.core.runtime.compatibility.auth_3.2.200.v20100517.jar
+org.eclipse.core.runtime.compatibility.registry_3.3.0.v20100520/runtime_registry_compatibility.jar
+org.eclipse.core.runtime_3.6.0.v20100505.jar
+org.eclipse.equinox.app_1.3.0.v20100512.jar
+org.eclipse.equinox.common_3.6.0.v20100503.jar
+org.eclipse.equinox.preferences_3.3.0.v20100503.jar
+org.eclipse.equinox.registry_3.5.0.v20100503.jar
+org.eclipse.osgi.services_3.2.100.v20100503.jar
+org.eclipse.osgi_3.6.0.v20100517.jar
and my config.ini file has the following contents:
osgi.bundles=javax.transaction_1.1.1.v201006150915.jar#start, org.eclipse.core.contenttype_3.4.100.v20100505-1235.jar#start, org.eclipse.core.jobs_3.5.0.v20100515.jar#start, org.eclipse.core.runtime.compatibility.auth_3.2.200.v20100517.jar#start,org.eclipse.core.runtime.compatibility.registry_3.3.0.v20100520/runtime_registry_compatibility.jar#start, org.eclipse.core.runtime_3.6.0.v20100505.jar#start, org.eclipse.equinox.app_1.3.0.v20100512.jar#start, org.eclipse.equinox.common_3.6.0.v20100503.jar#2:start, org.eclipse.equinox.preferences_3.3.0.v20100503.jar#start, org.eclipse.equinox.registry_3.5.0.v20100503.jar#start, org.eclipse.osgi.services_3.2.100.v20100503.jar#start, ch.thobens.dd.commands_1.0.0.jar#start, ch.thobens.dd.common.items_1.0.0.jar#start, ch.thobens.dd.core_1.0.0.jar#start, ch.thobens.dd.game_1.0.0.jar#1:start
eclipse.ignoreApp=true
osgi.noShutdown=true
The bundles that are listed here are the same bundles that are selected if I select "Add required Plug-ins" in the run configuration. If I run these bundles from the Eclipse PDE, it works fine.
Additionally, there is no difference between running the command
java -jar org.eclipse.osgi_3.6.0.v20100517.jar -consoleLog -Dosgi.clean=true -Declipse.ignoreApp=true -Dosgi.noShutdown=true
and when I use the equinox launcher (via eclipse.exe).
Thanks for any help
I found the solution (through the eclipse product exporter):
The javax.transaction_1.1.1.v201006150915.jar is not an OSGi bundle itself, it's an OSGi framework extension.
I had to change the config.ini file:
Remove the entry for the
javax_transaction bundle in the
property osgi.bundles
added the following line:
osgi.framework.extensions=javax.transaction_1.1.1.v201006150915.jar