I am trying to deploy Apache Archiva on my Server, but it just fails all the time.
specs:
os: ubuntu 10.04
tomcat: Apache Tomcat/6.0.24
jvm: 1.6.0_27-b27
$CATALINA_HOME : /usr/share/tomcat6
$CATALINA_BASE : /var/lib/tomcat6
$CATALINA_OPTS : "-Dappserver.home=$CATALINA_HOME -Dappserver.base=$CATALINA_BASE"
path to lib : $CATALINA_BASE/common/lib
#java -version
java version "1.6.0_27"
OpenJDK Runtime Environment (IcedTea6 1.12.3) (6b27-1.12.3-0ubuntu1~10.04.1)
OpenJDK Client VM (build 20.0-b12, mixed mode, sharing)
Tomcat itself is up and running. I followed the instructions on this page, copied all the necessary jars to the lib (location specified above), created the archiva.xml in /var/lib/tomcat6/conf/Catalina/localhost/ with that content:
<Context path="/archiva" docBase="/var/lib/tomcat6/archiva/apache-archiva-1.4-M4.war">
<Resource name="jdbc/users"
auth="Container"
type="javax.sql.DataSource"
username="philipp"
password="xxx"
driverClassName="org.apache.derby.jdbc.EmbeddedDriver"
url="jdbc:derby:////localhost:1527/archivausers;create=true" />
<Resource name="jdbc/archiva"
auth="Container"
type="javax.sql.DataSource"
username="philipp"
password="xxx"
driverClassName="org.apache.derby.jdbc.EmbeddedDriver"
url="jdbc:derby://localhost:1527/archivadata;create=true" />
<Resource name="mail/Session"
auth="Container"
type="javax.mail.Session"
mail.smtp.host="localhost"/>
</Context>
After a click on »start« in the tomcat manager: FAIL - Application at context path /archiva could not be started
the last lines on the catalina.out are:
SCHWERWIEGEND: A web application created a ThreadLocal with key of type[java.lang.ThreadLocal] (value [java.lang.ThreadLocal#69bf9]) and a value of type [org.apache.logging.log4j.core.impl.Log4jLogEvent] (value [Logger=org.springframework.web.context.ContextLoader Level=ERROR Message=Context initialization failed]) but failed to remove it when the web application was stopped. To prevent a memory leak, the ThreadLocal has been forcibly removed.
11.06.2013 16:29:30 org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap
SCHWERWIEGEND: A web application created a ThreadLocal with key of type [null] (value [org.apache.logging.log4j.spi.DefaultThreadContextMap$1#1ea380c]) and a value of type [null] (value [null]) but failed to remove it when the web application was stopped. To prevent a memory leak, the ThreadLocal has been forcibly removed.
I tried more or less everything what came to my mind, but always FAIL!
Any Idea?
Since I could manage to get it running I think it could be useful for somebody else to share the steps I have taken. These descriptions assume that one has already has read the official installation Instructions of archiva and should be a kind of additional explanation due to the fact that the official documentation could be a bit more verbose.
First I downloaded the »war« and stored it in /var/lib/tomcat6/archiva, this defines the starting point.
1. Database:
In the official instruction one is asked to download derby.jar and derbytools.jar to save them in $CATALINA_HOME/lib (in my case that points to /usr/share/tomcat6/lib) to make the files available for all web application running on this tomcat. On my research I came over the apache derby project where I also found this command:
sudo apt-get install sun-javadb-core sun-javadb-client
which just installs the derby db (in my case I had to add »multiverse« in /etc/apt/sources.list at the of one source). After that I run:
sudo ln -s /usr/share/javadb/lib/*.jar -t /usr/share/tomcat6/lib
what linked all needed derby-jars to the tomcat lib (probably some are not needed there). After that I created the directory db in /var/lib/tomcat6/archiva and changed its owner and group to tomcat6, but it is up to you where you want to store the database files, but it is important not to create the two subdirectories for the two needed databases, namly: users and archiva, inside that directory.
2. Mail
There I followed the Instructions and copied mail.jar and activation.jar to tomcats library.
3. archiva home directory
One of the Errors that prevented archiva from running was that it tried to create a home Directory in /usr/share/tomcat6/.m2, but that resulted in an permission conflict, so I created that directory and changed group and owner to tomcat6.
Last but not least I cared about the archiva.xml, located in in /var/lib/conf/Catalina/localhost. Since the paths that should be replaced were not marked in »bold« it is kind of easy to oversee them, so I try to do that here, using ${path} to point that out:
<Context path="/archiva"
docBase="${path to the archiva war archive here}">
<Resource name="jdbc/users"
auth="Container"
type="javax.sql.DataSource"
username="sa"
password=""
driverClassName="org.apache.derby.jdbc.EmbeddedDriver"
url="jdbc:derby:${path to the db folder}/users;create=true" />
<Resource name="jdbc/archiva"
auth="Container"
type="javax.sql.DataSource"
username="sa"
password=""
driverClassName="org.apache.derby.jdbc.EmbeddedDriver"
url="jdbc:derby:${path to db folder}/archiva;create=true" />
<Resource name="mail/Session"
auth="Container"
type="javax.mail.Session"
mail.smtp.host="localhost"/>
</Context>
That should be everything and I hope that I did not forgot anything to mention. Searching the catalina.out for error logs is a kind of senseless since the messages in there do not describe explicit problems, therefor I want to suggest to read localhost.${date}.log in the same directory, therein I could find debug information which was much more useful.
p.s.: After the Installation of Archiva did the very same Steps for Apache Continuum, just replacing folder- and filenames, what resulted in a running Installation, too.
Happy Install, cheers!
Related
I have a deployment that calls javax.crypto.SecretKeyFactory.getInstance.
The class javax.crypto.SecretKeyFactory appears to load correctly, but when the method tries to create an instance it throws a NoClassDefFoundError on sun/security/jca/GetInstance
Looking at the OpenJDK8 sources shows that relevant javax.crypto.SecretKeyFactory constructor refers explicitly to a method in sun.security.jca.GetInstance, so it's normal that it tries to load it.
What's odd is that both javax/crypto/SecretKeyFactory.class and sun/security/jca/GetInstance.class are present in /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.91-1.b14.el6.x86_64/jre/lib/rt.jar but that only the former is found by the classloader.
What is the jboss module classloader playing at and how can I get it to stop it?
Thanks for suggestions.
Not all JDK classes are exposed to a deployment by default. If your deployment uses JDK classes that are not exposed you can get access to them using jboss-deployment-structure.xml with system dependencies:
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.1">
<deployment>
<dependencies>
<system export="true">
<paths>
<path name="sun/security/jca"/>
</paths>
</system>
</dependencies>
</deployment>
</jboss-deployment-structure>
Another alternative you can import the whole system module adding the following line to MANIFEST.MF:
Dependencies: system
Ref: Class Loading and Modules
In your JBoss installation, go to directory modules/sun/jdk/main and edit the module.xml file there. In <dependencies>/<system>/<paths> add an element <path name="sun/security/jca"/>. Restart your JBoss instance and retry.
I finally fixed my problem, though not quite in the ways suggested above. I wouldn't have got there without the help though (thanks guys).
I did manage to fix the sun/security/jca access problem but it then threw up another problem of a similar type, but with a javax class. I found an ugly fix for that by removing a jar from module org/jboss/genericjms and letting the jdk version get picked up, but I felt that that was playing around too much with stuff that I couldn't predict the consequences of.
The fix I have finally settled on is to put the provided jar that references javax/crypto/SecretKeyFactory in a new module all of its own and then to pull in the classes it needs via:
<system export="true">
<paths>
<path name="java/sql"/>
<path name="javax/crypto"/>
<path name="javax/crypto/spec"/>
<path name="javax/crypto/interfaces"/>
<path name="javax/management"/>
<path name="javax/security/auth/login"/>
<path name="sun/security/jca"/>
<path name="org/ietf/jgss"/>
</paths>
</system>
in the module.xml. When I reference this new module from my code it works (I pulled it in by making it a global module in standalone.xml in fact).
Problem solved. Though I have to say that after this experience of the jboss modular class loader, give me a hierarchical one any day.
Thanks again for the help.
I have created a small sample project to have a reference implementation of OSGi with Spring (i.e. Blueprint), and I can get all bundles to install, resolve and start OK, but my service is not registered when the bundle starts.
I've made the entire project available on github so you can take a look at the source - the jars output from the build are in the artifacts folder, but you can also build the project yourself by running gradle assemble.
As I've understood the Blueprint specification, and particularly this guide, there is no need for an activator class to register the services if the configuration files are in the right place - in my jar, I have the following under OSGI-INF/blueprint/sillyservice.xml:
<?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0">
<bean id="sillyService" class="se.sunstone.silly.service.ServiceImpl"
init-method="startService">
</bean>
<service ref="helloservice"
interface="com.sample.blueprint.helloworld.api.HelloWorldService" />
</blueprint>
When deploying this bundle, JBoss reports the bundle as ACTIVE.
When I then deploy the client bundle, there is an activator class that runs the following snippet to list all registered services:
ServiceReference[] refs = context.getAllServiceReferences(null, null);
if (refs != null) {
logger.info(String.format("There are %s references", refs.length));
for (ServiceReference ref : refs) {
logger.info(ref);
}
} else {
logger.info("There are no registered services.");
}
A bunch of services that are registered by the OSGi framework inside JBoss are listed, but not my SillyService.
What do I need to do to make this work?
To enable Blueprint functionality, you need to install a Blueprint Extender bundle. There are two implementations available: Apache Aries and Eclipse Gemini. I recommend Aries, which is available from http://aries.apache.org/
I'm having a problem with my logj2.xml being seen on my Windows7/64 box running Java 1.7.0_13/64. I'm trying to run the application using the NetBeans/64 7.2.1 IDE via the debugger.
log4j2.xml is sitting in my r:\ directory. The (user)classpath is ".;r:\". It is apparently not being seen, because when I look at the 'config.config.name' of the Logger in my debugger, it gives me the value of 'Default'. Also, I can't find the file specified in the log4j2.xml file anywhere, on any drive, of my machine. I've also looked for any new files containing the word 'default' on my machine, and can find none that are current.
So I suspect I'm doing 1 of 2 things wrong:
1) Setting my classpath incorrectly.
2) Putting my log4j2.xml file together incorrectly.
Any help would be appreciated. My keys are getting sticky from banging them with my forehead.
Here's the config file:
<?xml version="1.0" encoding="UTF-8"?>
<configuration status="debug" name="xxx" packages="" >
<appenders>
<RollingFile name="log" fileName="qqq.log"
immediateFlush="true" filePattern="qqq-%d{yyyy-MM-dd}.log">
<PatternLayout>
<pattern>"%d{YYYY-MM-dd HH:mm:ss} [%t] %-5level %logger{36} - %n%msg%n%n%n"</pattern>
</PatternLayout>
<Policies>
<TimeBasedTriggeringPolicy />
<SizeBasedTriggeringPolicy />
</Policies>
<DefaultRolloverStrategy max="92"/>
</RollingFile>
</appenders>
<loggers>
<root level="trace">
<appender-ref ref="log"/>
</root>
</loggers>
</configuration>
Ok, got it. I've renamed this question to include NetBeans, because that was the gist of my problem.
As a review, it is required that the log4j2.xml file needs to go on the classpath. While I could affect the classpath in netbeans by adding jar files to the project, I didn't initially think about finding a config file on the classpath. Anyway, once I realized that, I played around a bit in project properties, and finally figured out that just adding the folder to the 'Compile-time libraries' dialog ( in this case "r:\" ) puts the config file on the classpath, and my logging works just like it should.
Whew!
Hope this helps someone.
Thanks joe7pak, your posts were the last piece of the puzzle to solve my log4j properties problem in NetBeans. My problem required a couple extra steps that may help round this solution out.
First, I created a log4j.xml file in the src directory using the default xml from http://wiki.apache.org/logging-log4j/Log4jXmlFormat.
I then set the NetBeans VM options in Properties\Run to: -Dlog4j.debug. I noticed that a jar's (httpbuilder) log4j.xml file was being loaded by default instead of mine.
So I added the src folder to the compile time libraries in Properties\Libraries using your recommendation. However, it was still loading the log4j.xml file from the jar.
The final touch was to move the src folder to the top of the compile time libraries.
Thanks for your post and for answering yourself.
I downloaded wicket examples 1.6.0 and built successfully in netbeans7.2. but got errors when I tried to deploy on tomcat 7:
Cannot deploy the module. The context.xml file seems to be broken. Check whether it is well-formed and valid.
The module has not been deployed.
See the server log for details.
at
org.netbeans.modules.j2ee.deployment.devmodules.api.Deployment.deploy(Deployment.java:210)
at
org.netbeans.modules.maven.j2ee.ExecutionChecker.performDeploy(ExecutionChecker.java:178)
at
org.netbeans.modules.maven.j2ee.ExecutionChecker.executionResult(ExecutionChecker.java:130)
at
org.netbeans.modules.maven.execute.MavenCommandLineExecutor.run(MavenCommandLineExecutor.java:212)
at
org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:153)
heres the contents in context.xml:
<?xml version="1.0" encoding="UTF-8"?>
<Context>
<!-- <Loader className="org.atmosphere.util.AtmosphereClassloader"/> -->
<Loader delegate="true"/>
</Context>
I prefer to run wicket in eclipse as it negates the requirement to mess around with an external tomcat instance.
If you are comfortable with eclipse and maven i would download wicket 1.6 example archetype via maven, import into eclipse and then in the test directory you can run the run.java class to get an internal jetty server host wicket for you.
this should get you started quickly without having to wrestle with tomcat configurations too.
Not really an answer but an alternative route to the same end point
Add parameter path to context tag, same path that app will be served:
<?xml version="1.0" encoding="UTF-8"?>
<Context path="/application-path-name/">
<!-- <Loader className="org.atmosphere.util.AtmosphereClassloader"/> -->
<Loader delegate="true"/>
</Context>
Answer obtained from this question.
I get an UnsupportedClassVersionError thrown when launching jnlp, however when I try to run the relevant jar files from command line everything works fine. I tried setting j2se versions to 1.5+, 1.6+, using signed/unsigned jar files, but all that doesn't help.
I'm trying to launch my own jar file with two supporting jar files (mysql-connector.jar and swingx.jar). My jar file has been compiled with 1.6 compliance settings in Eclipse and built into a jar with ant. Since I can launch the 3 jars from command line using java 1.6 I'm a bit baffled that jnlp fails. Any help is appreciated.
Here is the jnlp file:
<?xml version="1.0" encoding="utf-8"?>
<!-- JNLP File -->
<jnlp spec="1.5+" codebase="http://www.etc.com/p" href="demo-daily.jnlp">
<information>
<title>demo: daily stock charting utility</title>
<offline-allowed/>
</information>
<security>
</security>
<resources>
<j2se href="http://java.sun.com/products/autodl/j2se" version="1.6+" />
<jar href="demo-daily.jar" main="true" />
<jar href="swingx.jar" main="false" />
<jar href="mysql-connector.jar" main="false" />
</resources>
<application-desc main-class="quipu.viewers.charts.stockcharts.daily"/>
</jnlp>
The error I get is:
java.lang.UnsupportedClassVersionError: Bad version number in .class file
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:675)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at com.sun.jnlp.JNLPClassLoader.findClass(JNLPClassLoader.java:256)
at java.lang.ClassLoader.loadClass(ClassLoader.java:316)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at com.sun.javaws.Launcher.doLaunchApp(Launcher.java:1052)
at com.sun.javaws.Launcher.run(Launcher.java:105)
at java.lang.Thread.run(Thread.java:613)
First, open a CMD window or a shell window (as appropriate to the OS you're using) and type this:
java -version
to ensure that the version you're running is the version you expect to be running. Then, again from the command line, issue the command:
javaws http://host/path/to/your.jnlp
If you cannot run javaws from the command line, then you'll have to find out where it's installed and use the full path to the executable. Under Windows, this will be something like
C:\Program Files\Java\jre1.6.0_14\bin\javaws.exe
and under Linux it may be /usr/bin/javaws or it may be in another directory.
I know under Windows, at any rate, when you run any Java Web Start app, the JNLP loader is used from the most recent Java version installed. Or at least it's supposed to do this. I haven't experimented under Linux (or MacOS) to see how it works there. But it's always possible that something has gotten messed up and when you launch a JNLP you are accidentally running a Java 1.5 JNLP launcher.
You can always try to uninstall and re-install the most recent version of Java to ensure that the latest and greatest version is properly installed. This may fix things. You may also want to check your $PATH (or %PATH%) to ensure that the correct version of Java is on the path. (This is not always necessary ... but if any version of Java is on the path, ensure that it's the version you want.) Check the environment variable JAVA_HOME to make sure it points where you think it does.
Just a guess, but update the opening tag to reference spec="1.6+"
<jnlp spec="1.6+" codebase="http://www.etc.com/p" href="demo-daily.jnlp">