I have multiple application deployed in mule esb. All these application have same set of jars so I am trying to create a shared library . If I place all the jars in %mule_home%/lib/user then it works fine, but I am trying to put these jars into my custom folders.for example %mule_home%/lib/user/hibernate then I am not able to deploy my applications.
Ok let's say that if you where using maven you didn't had this issue, as everything was packaged with your deploy without issues.
Anyway if this is still the way you want to go it's normal that he will not pick up on subfloder, they are not on the path.
One way you have is to create an unique jar containing all your jars and that put it in lib/users.
There is probally also another way, even if I didn't tested it and I would also not encourage.
You could go play with the mule wrapper.conf and add folders to the classpath, as you can see around the line 118 of the file:
But again I do recommend you to use maven for painless (more or less) dependency management.
Mule allows libraries seperation by using the domains. The application domain can be configured in mule-deploy.properties. For example:
domain=hibernate-apps
Place all your libs the needed libs into the domain folder. Has been tested with Mule 3.8.5.
Related
I'm currently in the process of creating a web service to be deployed onto an existing Jetty 9 server. I decided to use maven to handle the dependency management for this application and it is creating a bit of a problem. When I try to start the app, it is failing due to library conflicts. I figured out that the source of the problem is that the classpath is including both my maven dependencies and the jars in $JETTY_HOME/lib/ext/. I can't simply rename or delete lib/ext since there are existing applications on the server that depend on those libraries.
Is there a way to configure jetty to include or exclude lib/ext from the classpath on a per-application basis? If not, is there some other way I can work around this problem?
TL;DR - I don't think there is a simple answer.
According to the documentation, the jars in the lib/ext directory are added to the classpath by the "ext" module. So, you could in theory disable the "ext" module. But that will remove the jars from the classpath for all of the web services in the container. So that won't work ... except for testing purposes.
So that leaves you with a couple of more drastic solutions:
Set up a separate Jetty server to run the new webapp. (For example, using Docker containers.)
Analyze the other webapps to determine which of them use the JARs in the lib/ext directory, and rebuild their WARs so that (at least) the conflicting dependencies are in the WARs that need them rather than in lib/ext.
This is probably what you should do.
Go on a Jetty code hacking spree and modify the way that Jetty builds the "server" classpath. Anything is possible, if you are prepared to put in enough coding effort. But you will be creating "technical dept" for yourself by (in effect) creating a private fork of Jetty. So this is a really bad idea.
I have a number of internal projects that are essentially client-side web assets that I'd like to distribute to colleagues as webjars via our repository manager. So far the development process has been:
Build an example webapp that includes the web assets I'd like to distribute and test.
Create a separate project with copies of the assets located in src/main/resources/META-INF/resources rather than src/main/webapp; set <packaging> to jar rather than war in pom.xml. Build and deploy the jar artifact to the repository manager.
Create a third project as a testbed to verify that everything works correctly when the jar file from (2) is included as a project dependency.
I'd like to combine (1) and (2) so that I can test and release from a single project. I'll need to get Maven to selectively move the distributable assets to the right locations. Seems like I'd also need a way to switch <packaging> as well. Any suggestions on how to do this or better alternatives?
Unfortunately I don't think there is a good way to deal with this when using WAR-based webapps because WAR files aren't like JAR files. If you were using a non-WAR-based web framework (Play Framework, Dropwizard, etc) then you could definitely keep JAR packaging and have both the static assets and the testing app in a single JAR.
I wonder if this is a somewhat awkward way of thinking, but I couldn't really find any hint on the internet to my idea. Maybe I just did not phrase my question right, but anyhow, this is what I would like to do:
I have a complex application written in java with spring and quartz and a whole load of dependencies. The application is run inside an apache tomcat servlet container. Now I know, I can create a war file and deploy that to the productive server machine (after our internal IT has installed and configured the tomcat on that machine), but I would like to do this a bit different.
I would like maven to create a pre-packaged tomcat application server with all dependencies and configuration settings AND my application. In effect, all that would need to be done on the productive system is, copy the package (or zip or tar.gz or whatever is needed) to the server, unpack it in a directory of my or their choice and fire up this local isolated tomcat. It would only run my application (which poses enough load on the machine anyway) and I could even go so far and deploy a second variant, say for a different customer in the directory next to the first one. Neither of both could interfere with each other, even if they use different versions with different dependencies.
Is it possible to do that? Is it a desirable approach or am I on the completely wrong track here?
What I think would be a benefit of this approach (despite the thing with incompatible dependencies or settings between two or more different installations) is, that I can hand the whole package over to our administration guys and they can simply deploy it to a server without the need to configure anything in the tomcat after installing it and so on.
Any hint???
Create a Maven project as the parent project (type pom). Include your webapp as a module project (type war). Create another module project, maybe "myapp-standalone" (type jar) and include the Embeddable Tomcat as a dependency. Write a starter class to launch the internal Tomcat (see executable jar / überjar). When building the app, copy the created war file into the jar, into Tomcats webapp directoy.
Your launcher class needs to make sure, that the ports of the current Tomcat are not yet in use.
In my GWT web app I am keeping all my jar files outside of my project and referencing them using classpath variables. This allows me to link to jars from other projects/teams without having to put a copy of the jar in my web app lib directory. Hosted mode kindly looks up the classes in this system classpath and then adds them to the web-app classpath warning me that it is doing so. When I deploy my build system pulls in only the jars I need to ship in my web app and is not a problem.
The issue I have is that some code uses dynamic lookups, searching the classpath for implementations. If a jar has not yet been added to the web app classpath beacuse no classes have yet benn loaded from the jar it is not included in the search.
The particular problem I am having is with Persistence - it looks up EntityManagerFactory implementations by searching for META-INF/services files. I have also had a similar problem with Rome and its module extensions.
I have got a workaround, in the dev/hosted mode I simply refer to a class I know is in a jar I want and this causes it to be added to my web app classpath. I do this my by calling
private void devModeClassPathHack() {
Class<?> gwtDevModeHack1 = EntityManagerImpl.class;
}
from my development mode Guice module.
My question is simple - is there a "nicer" way of doing this?
I don't think, there's a nicer way - using this makeshift "self-healing" mechanism of the GWT Jetty/dev mode is already a hack :) If you ever have the need to run the server side code on e. g. JBoss during development (together with GWT dev mode for the client side), this will stop working.
(As an additional problem, the order of classloading - and consequently the precedence in cases when there are multiple versions of a class in different jars - will depend on program flow. This can be very nasty to debug.)
You mention, that you pull in all the jars from outside. What I would do in that case, is to set .svnignore (or .gitignore/...) to "*.jar" in the WEB-INF/lib dir. Then I'd run the same build step which is used to create the production build to copy the jars into the lib dir before starting the server.
I am having four different project, and i am using Weblogic to deploy my projects. There are several libraries ( jar files ) which are common for all projects. Currently each of my project are having lib directory and have almost same set of libraries. Now, is it possible to have this lib directory outside WAR files and access them.
Resist the temptation of putting the jar files in the "shared" folder of your container. It is better to keep the jar files where they are now. It may sound a good idea to use a shared folder now, but in the future you may need to deploy an application that requires a shared library, but a different version.
That being said, I have no experience with WebLogic. In Tomcat there is a shared folder with libraries common for all deployed applications. It is not a good idea to use this. If WebLogic can be configured to use a shared folder per a set of applications (and not for all deployed applications) you could go for it.
Do you want to do this ? Unless you're stuck for deployment space, I would (perhaps) advise against it.
Why ? At the moment you have 4 solutions running off these libs. If you have to upgrade one of the libs (say, if you discover a bug, or if you require a new feature), then you're going to have to test compatibility and functionality for all 4 solutions. If each solution has its own set of libs, then they're sandboxed and you don't have to move all 4 in step.
Note that all this hinges on how easy it is to regression-test your solutions. You may find it easy, in which case using the same set of libs is feasible.
Don't do that.
The whole idea of WAR files is that they are self-contained units. This makes deployment so much easier.
In addition to the possible version conflicts that others have pointed out, putting jar files in /shared can have very nested consequences for class visibility. They will be on a separate classloader, and be unable to see the classes in the WAR file. If you use libraries that rely on Class.forName() to work (and there are plenty), this could get very painful.
If you really, really cannot afford the extra disk space and memory look at OSGi or Spring DM. They have solved this problem, but at the price of increased complexity.
Put all the shared jar files under common\lib folder of weblogic. common\lib is accessible by all the deployed apps.
Well first of all you can put your libs all on the same place and have your build process import the ones needed.
Has for on deploy the new Weblogic 10 has a lib folder in each domain where you can put shared libs. i dont think that is possible before Weblogic 10
You can put the jars in their own ear file and deploy it as a shared library.
You can also put the wars in an ear and add the shared jars to APP-INF/lib. This is a Weblogic extension of J2EE, so it won't work on other servers.
I'm currently using another approach.
Create a central repository folder and put all common libraries in there.
In each project you can create a reference to all needed libraries. In Subversion it works with externals
Everytime, the local working copy is updated, the externals are updated to, so you just need to commit to the central folder and it's automatically distributed to all projects.