In my application I am using Joda-Time 2.0 but in my WebLogic path there is library Joda-Time 1.2.
How can I change the order and tell WebLogic to use my library? Now it is using its own library, not mine. I just added a Maven project dependency to Joda-Time 2.0.
There are several ways of doing this.
Change your startWeblogic.cmd(sh) in the bin folder for your domain, look for the classpath setting and add the new joda before any other WebLogic jars
as was said above, you can change your weblogic.xml if the application is a web application and chose to prefer any lib that comes inside the war.
If you are using an Enterprise application, you can set the following options in your weblogic-application.xml:
<prefer-application-packages>
<package-name>org.apache.*</package-name>
<package-name>antlr.*</package-name>
</prefer-application-packages>
And set your package name for joda in there.
Please note that the first option might result in strange behavior from WebLogic.
Note for some reason I can't get the code to work with the XML.
As your class is present in your war, WEB-INF/lib,
can you try using the weblogic.xml setting to force the WEB-INF/lib class to get loaded in preference to that in server/lib with
<container-descriptor>
<prefer-web-inf-classes>true</prefer-web-inf-classes>
</container-descriptor>
Related
I have a project deployed on websphere 8.5. However, there are certain classes that are creating conflict due to jar version errors in project and the ones provided by websphere default.
Can anyone help to point mechanism to resolve conflict.
I have done something similar in weblogic which provides option in welogic.xml to exclude / include jars from project.
This is the use case for the "isolated shared libraries" feature in the WebSphere server. For any technologies for which you need to bring your own version rather than use the version provided with the server, place the necessary jars into some directory outside the application, create a shared library pointing to that location, select the "use an isolated class loader" option in the library configuration, and associate the library with the application(s) that require it. The application will search the isolated library class loader before delegating to its parent loaders, and classes there will be found instead of server-provided versions.
A few cautions: This should ONLY be used for technologies that you are 100% certain that you need your own version rather than the server's. The "parent last" style of class loading used by isolated shared libraries includes some risk of conflicts between class loaders, and avoiding it (by using APIs provided by the server) is generally the safer option.
Note, too, that not everything can be overridden. The Servlet, EJB, and JPA APIs, for example, will break application startup if included in an isolated shared library, because the server containers require consistent versions of the API classes when processing application objects. Also, you cannot bring an API of any technology without an associated implementation - doing that is usually a recipe for a VerifyError or LinkageError caused by duplicate visibility to multiple versions of the API.
I hava met some problems .
I want to encrypt the war using Spring by a tool named ClassGuard ,but when I deploy it to Tomcat and started to launch it , some problems(seemed to be A fatal error has been detected by the Java Runtime Environment) arised .
have anyone used ClassGuard and met problems like this?
please help me...thanks in advance!
Although without the exception we can only speculate, the ClassGuard FAQ section clearly states that:
As of Version 1.5, ClassGuard supports Tomcat containers.
To use ClassGuard in combination with tomcat, you have to configure your web application for using the ClassGuard tomcat class
loader. This can be set in the context of the web application.
So make sure that:
You are using the latest stable version.
You are using the appropriate class loader.
A probably (although not sure if it is what you are after) easier way to discourage usage of your code would be through Obfuscation Tools such as these.
At the moment, the Hibernate Validator has released the latest version as 4.3.0.Final here. I have tried to upgrade it to my Glassfish 3.1.2 as the following step: -
1. Remove the GLASSFISH/glassfish/modules/bean-validator.jar
2. Copying the hibernate-validator-4.3.0.Final.jar to GLASSFISH/glassfish/modules
3. Restart the Glassfish
4. The Glassfish cannot start. It seems hang.
After searching via the Google, I've found that the file named "bean-validator.jar" was created by the Glassfish team as an OSGi version. Sadly, I cannot find how to create it. Could you please help to advise further? Thank you very much for your help in advance. I'm looking forward to hearing from you soon.
A (slightly outdated) description of how to build Glassfish's bean-validator.jar can be found here.
What's needed in general is an OSGi bundle which includes Hibernate Validator itself and the Bean Validation API. With this bundle you should be able to replace the original bean-validator.jar. Additionally you need the JBoss Logging bundle, which is used since release 4.3 by Hibernate Validator as logging API and already comes in form of an OSGi bundle.
If you're building a web application, you could also package HV 4.3 within your WAR and turn off class loader delegation by providing the file WEB-INF/glassfish-web.xml with the following contents:
<!DOCTYPE glassfish-web-app PUBLIC "-//GlassFish.org//DTD GlassFish Application Server 3.1 Servlet 3.0//EN" "http://glassfish.org/dtds/glassfish-web-app_3_0-1.dtd">
<glassfish-web-app>
<class-loader delegate="false" />
</glassfish-web-app>
That way the HV classes will be loaded from your application instead of from the module provided by Glassfish.
You might also be interested in the issue GLASSFISH-15648 which aims to provide a dedicated Glassfish update package for HV.
As my case was ear, rather than war, based on suggestion of Gunnar, I did a patched version of the module, that is deployable to Glassfish (My version is 3.1.1 OSE).
Someone might find it still useful, see my blog for my solution (including step-by-step approach): http://peter-butkovic.blogspot.de/2012/11/glassfish-311-oss-with-hibernate.html
My application supports running on many dbms and it requires user to configure dbms connection setting and also provide the jdbc jar file.
Now the application is to be packaged as OSGi bundle. There will be another main jar which lanches OSGi server and starts the application as bundle.
Can you please suggest how can I package the application as bundle and let user provide the jdbc jar file.
Will it require something like the main launcher jar specifying JDBC driver classes as FRAMEWORK_SYSTEMPACKAGES property?
Thanks in advance,
Aman
There are two ways of doing this:
1) Adding the driver.jar to the classpath of the main launcher and, like you say, expose its packages via the framework by specifying that property (or actually you can use the FRAMEWORK_SYSTEMPACKAGES_EXTRA property to just specify additional packages, instead of specifying all of them).
2) Manually wrapping the driver.jar as a bundle, or doing it dynamically at runtime. For example, you could try to wrap bundles that are copied to a certain folder (similar to what Apache Felix File Install does) by using Pax URL or some other tool that can create a bundle out of an ordinary jar file for you (see http://team.ops4j.org/wiki/display/paxurl/Pax+URL).
I have some problems regarding the EJB injection and I haven't been able to find a solution anywhere.
My situation is the following: I have an EAR file that includes a WAR and several JARs, all listed in the application.xml file. All is working fine for this part.
The problems come out when I try to add what we can call a “plugin system”.
I have a JAR with inside some .xhtml pages, backing beans and EJBs. This JAR, if needed, is inserted inside the EAR in a specific directory (let's call it “plugins”) and is detected from the application at startup.
When the JAR is detected it's path is added to the WAR class loader so all the pages and the backing bean are detected without problems. What is not working is the injection of the EJBs (I tried to use the notation #EJB, #Inject, the lookup...). I can't inject any of the EJBs that is inside the JAR plugin.
My guess is that the application server treats the JAR as a simple library module and doesn't look for any EJB inside it, so they are inside the JAR but not usable from the application.
My question is: there's a way of having this working? I tried to add the JAR in the EAR's MANIFEST.MF but nothing changed...
the application server i'm using is glassfish 3.0. About the application.xml: there's no reference in it about the JARs that are part of what i called "plugin system". This because i detect them when i deploy (or i restart) the application in the application server, so they may or may not be inside the system and i don't really know that before the system is started.
Each plugin JAR is a "collection" of pages and functionalities that can be added or removed from the system dynamically (more less like a real plugin system).
My EAR structure is the following:
MyApp.EAR
META-INF
lib
plugins
plugin1.JAR
app.WAR
logic1.JAR
logic2.JAR
for example: in the application.xml i have the references for app.WAR, logic1.JAR and logic2.JAR (they are always inside the system), at startup the application looks inside the folder "plugins" for any plugin (specific JARs) to be added to the system.
I hope i've been more clear about what i'm trying to do...
It seems that the EJB are not even registered in the JNDI tree of the server. Which application server are you using? You can have a look to this JNDI tree to see if the EJBs are there, but the way to do this depends on the specific server.
How are you declaring the JAR that contains the EJBs in the EAR application.xml?
It should be someting lide this:
<application>
....
<module>
<ejb>nameOfTheJarFile.jar</ejb>
</module>
</application>
The Jar should be in a the "/lib" directory of the EAR.
I hope this helps.