Third-party libraries are often included by the appliation server you are deploying to and class with the ones included by your application. So far I have dealt with this in the simplest and hackiest way possible: removing the libraries on the app server.
In our case it is ok, noone is relying on the app server to provide them with any libraries. But if I were running my app along with lots of other peoples app, which again might depend on the libraries included by the application server, this would not be a solution.
How is this supposed to be solved (cleanly)? How are you doing it?
An example of a problem might be this:
you build an jax-rs application using cxf, hibernate and jackson, and deploy to glassfish 2.1.1. glassfish supplies the asm 3.1 library, but this causes clashes with hibernate using an incompatible 1.5 version. similarly the application needs jackson 1.8.2 (due to a bug fix), but glassfish 2.1.1 ships with version 0.9. BOOM. Any way of fixing this other than simply removing offending libraries?
consider using :
asadmin deploy --libraries ...
Related
I'm using Mule Server 3.8 EE which brings commons-lang 2.4 with it. A third-party library in my project needs commons-lang 2.6, because it uses a method that was introduced in this version.
So when I just start my application, I get a java.lang.NoSuchMethodError
Is there a way to update the dependency in the runtime? What I tried so far:
including commons-lang 2.6 in my app -> no effect, the one from the runtime is picked up first
replacing the jar directly in the runtime -> errors in studio, that the 2.4 jar is missing
so maybe i am late BUT -- this is your answer. Add the libraries that are newer in the jar distribution to the Build Path. Under Java Build Path screen you should see the libraries listed. I needed to use Apache http-client 4.5.6 and that's very interesting because it brings with it a lot of other dependencies, so your question was VERY relevant. The solution is to rely on JAVA (and not mule -- oops Anypoint or whatever) conventions and make sure the JVM loads my class files first. Then, it won't load the old ones from mule's jar. And so I went to the tab Order and Export, and moved Mule to the bottom. This simple, trivial change makes it work. I think if we would work with command line and vim, we would all know this. But all the IDE gui and everything else makes us forget the simplest things. Please use it in good health. :)
I am an absolute novice with Apache Geronimo, so my forgive my obvious ignorance.
Apache Geronimo ships with older versions of the HTTPCore and HTTPClient libraries. The current version of OpenID requires at least v4.1 of both HTTPCore and HTTPClient. I have found the OSGi Bundle page in the Geronimo Console, and see how to use this to install a new bundle. I also see that existing bundles have an "update" option, although this does not seem to update either of these bundles to the latest version.
Is there an easy magical way to just update these? If I need to download bundles for the appropriate version, where, exactly, would I go to download them? I've located and downloaded JARs for these two libraries, and have included them in my project and been able to package it with Maven, but this doesn't (apparently) deploy the updated versions into Geronimo (i.e., it loads the old versions and I get runtime errors).
If I had bundles for the later version, the UI is pretty obvious as to how to install them - will that replace the existing version, or will I then have both versions installed? Will this present a runtime issue? If so, how do I remove the exiting bundle (I see no way via the UI to accomplish this).
Any assistance is greatly appreciated.
David Mullin
Q: Are you using Glassfish 4 and CDI, and have no problems with anonymous inner classes? If so, please give me a hint which version of which CDI framework you are using.
Background:
Glassfish4 brings its own CDI framework, which is Weld 2.0 (downloaded a few days ago). After deploying my first application, I encountered errors. My software has lots of anonymous inner classes, and these caused errors. By googling, I found that Weld 2.0 doesn't work in the presence of anonymous inner classes (cf. https://issues.apache.org/jira/browse/WICKET-5226).
This problem should have been fixed in Weld 2.2. Both Weld 2.2 and 2.3 are available, so I tried to use these with Glassfish4. But appearently you can't just throw some Weld release into Glassfish's module library, as Glassfish brings its own adapters for Weld that are version specific.
I also tried to use another CDI framework (Openwebbeans), but this appears not to be accepted by Glassfish at all.
Please excuse that I don't yet give more specific info like stack traces, server messages, and the like. These would fill lots of space (and your time). I decided the best way to go is to first determine which version of CDI framework definitely works at some place, and then go into the detail work with that framework.
Anyone had any luck getting Ninject to work on MonoDroid? i've tried the 2.0 and 4.0 mono builds from their website and also tried the .net versions.
With the Mono builds i'm getting a MissingMethodException in the instantiation of my StandardKernel
I am experimenting with Ninject on a combined WP7/Monotouch/Mono for Android project and Ninject works surprisingly good.
I used the latest sources, which contain a project file Ninject.WP7.csproj which seems to be outdated. It contains a lot of DefineConstants. I created new WP7/Monotouch/Mono for Android solutions with these constants and everything compiled and works!
Constants used:
SILVERLIGHT,SILVERLIGHT_40,NO_LCG,NO_ASSEMBLY_SCANNING,NO_WEB,NO_PARTIAL_TRUST,NO_SKIP_VISIBILITY,NO_EXCEPTION_SERIALIZATION,NO_DEBUG_SYMBOLS
not sure if they are all needed, but the SILVERLIGHT one is important because Monotouch/Mono for Android implement a large part of the Silverlight api.
Of course you cannot create Android Activities with Ninject. I use it mainly for constructor injection, to create .Net objects like a ViewManager, view models using a repository, etc., the usual things you do with dependency injection.
I haven't tried to get Ninject working, but I'd be very surprised if it just worked out of the box. If there's a Silverlight build of Ninject you may have more luck with that, but there are no guarantees. The "best" way to get support for it in Mono for Android would be to build the code against the Mono for Android profile as a class library.
That said, there are other options out there for doing service location in your apps. I have a blog post up here that talks about using TinyIoC and Funq for service location.
I'm working on a cross-platform solution currently. The solution uses XmlMtomReader and XmlMtomWriter from .NET framework 3.0.
Now i need to know if these two classes (and all the nessasary infrastructure around them) are fully supported in Mono project from the porting-it-to-linux point of view. :)
You can check it on the mono status:
http://go-mono.com/status/
You can also check your code using the mono migration analyser
http://www.mono-project.com/MoMA
I checked they are currently not implemented
The APIs are available on the current Mono 2.6 preview, but they are not available on the 2.4 release (the current official release).