I've deployed the railo-3.2.3.000.war and I get the welcome page at http://localhost:8080/railo-3.2.3.000/ which is great but what now? How do I make my CFML-based vhosts actually recognise and use it? In particular, can it be done so all my existing 50+ vhosts share that one deployment and in a way that I can automate new vhosts (like through the manager script interface)?
Do I need to manually edit catalina.properties to load JAR's from /var/lib/tomcat-7/webapps/railo-3.2.3.000/WEB-INF/lib/? Or is there another way?
I'm really trying to avoid modifying Tomcat core files because I want a solution that's easy to roll out to other servers and upgrade in the future.
You probably do not want to use a WAR deployment for multiple virtual hosts. You would generally use a WAR deployment for each virtual host. You want a "global install" or "common classpath" style installation. In a nutshell, this involves dropping Railo JARs in a common Tomcat classpath and adding various servlet (and other) config info from a Railo WAR's web.xml to Tomcat's global web.xml file. There are plenty of guides and blog posts out there if you'd like to handle this manually, but if you don't have a reason to do otherwise, I'd recommend looking at the Vivio Technologies installers:
http://www.viviotech.net/company/installers.cfm
Here's some documentation for the Vivio Railo installer:
http://wiki.getrailo.org/wiki/Installation:InstallerDocumentation
And here's some more installation guides type stuff (potentially a few dated references under there):
http://wiki.getrailo.org/wiki/Railo_Installation
Once you have a global installation set, adding additional virtual hosts is a simple matter of modifying Tomcat's server.xml file with new Host entries. You should find details and examples of this in the above Vivio Railo Installer documentation. You may also be able to use Tomcat Admin Web apps to do the same, but I've always edited server.xml myself, and skipped installing Tomcat Admin apps altogether. HTH!
Related
I am trying to do a log4j migration for a legacy application. I made the changes to the configuration files and tested it locally with Tomcat, where the logs were displayed correctly. However when I deploy on WAS, the logging stops.
I checked a lot of pages about the necessary dependencies and the possible problems, but now I feel I'm stuck. Here is what I already tried:
Added the log4j jars manually to the lib/ext directory in WAS (together with commons-logging, I read an article where it helped, although all these jar-s were already present in the ear)
Double checked, that the configuration file is on the classpath and that it's syntax is correct
Added logj42-web dependency
Added the necessary filters in web.xml (Spring version is 3.8, so also the config listener with the config name context-param)
Checked classloader in WAS - it's parent first
Am I missing something?
Any ideas are appreciated. Thank you in advance!
WAS includes its own commons-logging API (that does not utilize Log4j), so bringing your own logger requires a bit of extra class-loader-related config. Typically, that would go something like this:
Put your commons-logging and log4j jars, along with your logging properties files, in some directory (not WAS_HOME/lib/ext) readable by the user running the server.
Create a shared library on the server, with that directory as its class path, and select the "use an isolated class loader" option. Associate that shared library with your application or web module.
Ideally, that should be it. Isolated shared libraries search themselves before delegating to the server's loaders, so your application will "see" the commons-logging/log4j classes in the shared library instead of in the server, and likewise, it should pick up the configuration files from that directory instead of the ones found in the server.
You can also accomplish this same basic thing by leaving all the logging stuff in your WAR or EAR and setting its class loader to parent-last (which causes the class loader to search locally before delegating to the server-level loaders), but that is a bit riskier configuration - if your application includes APIs that are also provided by the server, parent-last class loading increases the possibility of ClassCastExceptions or LinkageErrors.
I'm working on a project that uses two maven projects (named core and webapp); core is built with JAR packaging and used for two different purposes: as a stand-alone app (essentially an executable JAR), and also embedded into webapp.
For its purpose as a stand-alone app, core needs to have its own logback configuration (a logback.xml file) that needs to be included on the classpath. Normal Maven convention would have me put it in src/main/resources/logback.xml. That works fine, but causes a problem when the core JAR is included in webapp. webapp needs to have its own logback configuration, but the container (tc Server or Jetty) is picking up the one from core.jar first.
I realize that logback can be told about a custom config location via a system property (-D on the command line) but that's not viable in a app container like Tomcat or Jetty.
I've read some other people asking about this situation, but none of the solutions I've seen sits well with me. One solution involved setting up a context listener that runs early in the webapp initialization and explicitly configures logback based on a <context-param>. That's a bit brutish in my opinion, and probably a hard sell to my fellow dev team when log4j "just works" in this situation.
I'm far from a Maven expert, so I'm hoping there is some elegant way to get Maven to help me here. Or perhaps some logback extension or add-on that makes it more web-app friendly. Or even a clever idea that I haven't thought of.
There are a number of possible solutions, but the easiest is to put the file in its own module and mark the dependency as provided. The, conspire to have it on the classpath when running the standalone version of the app.
The solution that we ended up using was to leave only the common "non-app" pieces (code and configuration) in core and then extract the other "app" pieces into a new module (batch-app).
The logging configuration only lives in the 2 app projects (webapp and batch-app) that depend on core. core has a logback-test.xml configuration in it, but that's excluded from the JAR that maven builds (since it's in the src/test/resources folder).
I can successfully configure logback for a single web app and deploy it to Tomcat7 with the dependent jars in WEB-INF/lib. Then, when I move my dependent jars to the lib folder in CATALINA_HOME, it seems that the logback.xml config file is not found. I have a separate logback.xml file for each web app, sitting in the classes folder of each deployed war file. I have separate logback config files for each web app because I want each web app logging to a different rolling file appender, if possible. With some quick google searches, I failed to find documentation for this style of setup. Can anyone point me to a helpful resource, or just some good advice?
My boss, Venu, solved this problem yesterday by following a hunch. I suggested that he try to force tomcat to use logback for all of its logging, and then we may be able to control our logging in each of the web apps. When he tried that, it worked great. We then decided we did not need to log to different files for each web app because we can grep by the logger name, as our logging pattern includes it. A google search finds plenty of blog posts on how to force tomcat7 to use logback.
Is there a way to make the Websphere Application Server use the jar places inside the application's WEB-INF/libs folder and ignore the one that available within the server's plugin folder.
I am using EMF in my application and the version provided in the server doesn't include support for EMF GenericType, so I want to make the application use the jar file inside the libs folder.
Thanks for any help
This is quite possible. You need to change the classloading order from parent first to parent last. This will cause it to consult the server runtimes version of the code after your application. This is documented in the infocenter.
Another approach you might want to consider is to use an isolated shared library. There is a good introduction for those in IBM Education Assistant. These are more complex to setup, but using parent last classloading order can sometimes cause unexpected side effects that don't occur with isolated shared libraries.
I have problem with deploying JSR168 portlet using xmlaccess. I have no problem with deploy and join to conrete page but I would like to add shared library reference automatically. Is it possible?? I added shared library named 'libshared' using IBM WS console. Can I add this reference in input xml using by xmlaccess?
I don't think you can do this in xmlaccess. But you may try putting a reference to the library under the Manifest.MF file of the META-INF directory of your portlet's war file.
Or could just put the shared jar file under your /shared/ext directory. Or you could put it inside your wps.ear file. Mind you, either of these two solutions would share your library with the entire portal installation, rather than just select portlets.
You can deploy the application using wsadmin or similar and use that to update the classpath (i.e. for the shared library), you can then use xmlaccess to deploy the portlets and reference the previously deployed application - although I think this may only work in WebSphere Portal 6.1.
Give me a shout if you need further details.
I encountered this as well, a while ago... and researched it to the max, including spending some time chatting with IBM's support in various levels.
The XMLAccess protocol doesn't provide for such "system-level" configuration alongside Portlet application deployment; it can only be used to install, customize and uninstall Portlet applications and related artifacts.
If your deployment strategy involves deploying WAR files directly through XMLAccess, then you will have to manually add the shared-library to the application through the WAS admin console; this will have to be done manually because, when deploying WAR files through XMLAccess, an EAR with some random name is being created by WebSphere Portal to "host" your WAR file; hence you can't script the attachment of a shared library.
(alternatively, you may wish to add the shared library to the server's (WebSphere_Portal) classpath)
If your deployment strategy, instead, involves deploying Portlet applications packaged as EARs, then you're in a better position; you could automate the shared-library attachment as part of your EAR deployment process, then use XMLAccess to inform WebSphere Portal about the location, in the EAR, of your Portlet applications (which is what Michael mentioned above; it works in WebSphere Portal 6.0 as well).
Good luck.