Currently an EJB / Web Application project uses a JBoss-specific JNDI configuration file, placed either in the conf directory or in the Jar file (both works fine).
How can I make this project portable between JBoss (4.2.3 or 5) and GlassFish 3? Is there a recommended way to set different JNDI configuration parameters depending on the container?
According to their EJB FAQ, Glassfish developers have put a jndi.properties file within appserv-rt.jar. The JNDI machinery in Java SE automatically detects this file when used in conjunction with no-arg InitialContext() and bootstraps the correct naming provider.
My understanding is that this should work in Glassfish also. Did you try do deploy your application without the jndi.properties file specific to JBoss (and to place it into the conf directory when deploying on JBoss)?
Related
My current environment uses Linux, CentOS, WildFly 16. There are multiple datasources and it is all established externally in the standalone.xml. The application(s) in WildFly work just fine.
The issue I am dealing with is when I deploy the war file using command line interface (./bin/jboss-cli.sh) the application will use the existing datasource and I would like to change the datasource. For example App1.war uses MySqlDS1 datasource and App2_test.war uses MySqlDS2 datasource. I plan to overwrite App1.war with App2_test.war. The code will be mv App2_test.war App1.war . At that time the App1.war will be pointed to MySqlDS2 datasource, I believe since it now contains the App2_test code - that is the issue.
I need to change the App2_test.war file to point to MySqlDS1. I need to find the file that associates the URL to the datasource in the standalone.xml - I believe. I looked into web.xml but it does not exist in my war file and may not be provided in releases above EAP 6. I also looked into jboss-web.xml but unable to find file. I only have Manifest.mf in /META-INF and nothing in /WEB-INF/lib.
What file needs to be updated?
I have a possibly unique problem. We are using a thirdparty web library that uses log4j to log. Currently, our apps are set up to use the JBoss native logging.(We do this so we can vary the log printouts per environment)
The Thirdparty war file requires us to have a log4j.xml baked into the war its deployed in. Obviously we don't want that.
Here is what I have tried.
I have tried removing it and seeing if it will use the native jboss logger setup.
I have tried setting -Dlog4j.configuration to the path of the log4j.xml file.
I tried setting a system property of the jboss eap in the standalone-full file with the same name.
I dont have access to the source code, but I can decompile.
Any ideas?
I'm deploying all necessary Jetty bundles to an OSGi-container and launch a server instance. Yet although I'm deploying jetty-webapp and the corresponding jar contains the file org\eclipse\jetty\webapp\webdefault.xml, at startup I'm presented the error
java.io.FileNotFoundException: D:\eclipse\org\eclipse\jetty\webapp\webdefault.xml
(D:\eclipse is the eclipse installation I'm launching from)
Why isn't Jetty using the file it comes with? When I copy the file from the jar to the requested location, Jetty runs fine - but that can't be a feasible solution.
I wouldn't mind having to provide the file, but then again I don't know how to pass the path to Jetty. The launch happens directly from within an eclipse launch configuration, no maven involved.
If you use jetty-osgi-boot.jar, than you have to set the following system properties:
-Djetty.home.bundle=org.eclipse.jetty.osgi.boot
-Djetty.port=8080
The value is the symbolic name of the osgi-boot bundle that contains a default configuration.
More info in the documentation of jetty: http://www.eclipse.org/jetty/documentation/current/framework-jetty-osgi.html
Alternatively you can use the org.apache.felix.http.jetty bundle. You can find information about it here: http://felix.apache.org/documentation/subprojects/apache-felix-http-service.html
Or you can use Pax Web: https://ops4j1.jira.com/wiki/display/paxweb/Advanced+Jetty+Configuration
I used the jetty-osgi before. Nowadays I use the felix stuff as it can be configured via configadmin. Pax-web can also be used via configAdmin. I have not tried it yet but as much as I heard it has its benefits (e.g. better servlet context handling with HTTPService)
We want to simplify the deployment process of an app by including the MySql connector/j jar as part of the EAR. (so we won't need to manually copy it in the /lib folder of our Glassfish servers)
Is it possible?
UPDATE: We have read this is possible using the SAR files in JBoss, but we don't think it's available in Glassfish.
Because of the classloader hierarchy in Glassfish I don't think this is possible. The mysql driver jar needs to be available outside of your application's classloader because the connection pool is globally available.
http://download.oracle.com/docs/cd/E19226-01/820-7695/6niugesfp/index.html#indexterm-28
From what I can find, Glassfish doesn't support anything like .sar files:
http://old.nabble.com/Migrating-From-jboss-4.2.1-to-GlassFish-td18629992.html
Maybe vote for this issue, or create your own for a .sar-like deployment option:
http://java.net/jira/browse/GLASSFISH-16915
I have two tomcat web applications that need to share information using a singleton. I have already made it work by placing the jared classes in the tomcat common directory. Each webapp then gets the same copy of the singleton. What I would like to do is to integrate this behavior within eclipse. I would like the common classes to be a single project that gets incorporated into the tomcat common class loader every time I start the tomcat server within eclipse. Anyone knows how to configure eclipse to do this?
May be one possibility could be to extend the tomcat class loader in order for that class loader to search in other directories than WEB-INF/lib, this by:
Extending org.apache.catalina.loader.WebappClassLoader and override the findClassInternal method.
Configuring Tomcat to use the extended classloader.
This is done in the appropriate webapp configuration file under the Tomcat conf/Catalina/hostname path with the following element:
...
Then in eclipse, you could set your common project on the "Required projects on the build path", which makes it part of the classpath.
That means your extended classloader must be able to look for other classe:
either in a fixed pre-defined path
or in a pre-defined path within the classpath.
Not tested myself, but may be that can give you a lead on this issue.
A much simpler solution is proposed by noselasd in the comments, taking advantage of the GlobalNamingResources Component of Tomcat.
However, the FAQ does mentions:
When you create a new Tomcat server in Eclipse, the New Server wizard assumes it is not safe to affect the current behavior of the Tomcat installation that this new server will use.
WTP is able to avoid affecting the behavior of the installed Tomcat by using Tomcat's ability to run multiple server instances from a single installation. Thus, the default configuration for each new Tomcat sever you create will be a new server instance of the Tomcat installation associated with the Tomcat runtime selected in the wizard.
If you expect the new Tomcat server in Eclipse to run the same instance that the default batch files in your Tomcat installation run, you will likely be surprised when the Tomcat server in Eclipse doesn't behave as expected.
The Tomcat server configuration can be changed so that it does run the same instance as your Tomcat installation.
You will find here how to modify the server.xml in WTP.
I've managed to get it working. Here is what I did:
Created a common project in the eclipse workspace.
Created the two web applications, called first and second, that should share the common project.
When the web applications are created a Servers project is created with the tomcat configuration.
Change catalina.properties inside the Servers project and add the line shared.loader=/path-to-workspace/common/bin.
This works perfectly for development. Every time a new build is created everything is in sync. For deployment You need to convert the common project into a common.jar and place it in ${catalina.home}/lib.