I wrote a JSF application that uses a connection to an Oracle database. I verified on my local Tomcat (version 7.0) that everything works well. Then when being deployed to a server with a Tomcat 7 that I don't administrate, I get the following error thrown:
Caused by:
java.lang.NoClassDefFoundError - Could not initialize class oracle.jdbc.driver.OracleDriver
On my local system I have the Oracle JDBC Driver (version 11.2.0.4) in CATANIA_HOME/lib. According to the information I have of my deployment server, they use the exact same driver.
At the moment I am using a very basic JSF software that does nothing else than execute
Class.forName("oracle.jdbc.driver.OracleDriver");
on page load. Again, works fine on my local system. Fails on the deployment server. I figured that maybe they missed to include the driver, although they wrote they put it in. So I added the ojdbc5.jar to WEB-INF/lib. However then I get a SealingViolation thrown, which seems to indicate that the class loader found TWO resources containing the oracle driver.
If would be very happy if you were to give me some hints as to how I might solve this problem.
Thanks
Just put the driver jars in your WEB-INF/lib folder, in my case, I put ojdbc6.jar, you must have one ojdbc6.jar in your project, hope this help
Related
I have an application that runs just fine in a local tomcat instance - it's a cassandra client app that uses Hector as a client library for Cassandra. The application creates a keyspace and column family (if it doesn't already exist) using code like the following:
final ColumnFamilyDefinition cfDef = HFactory.createColumnFamilyDefinition(keySpaceName,
columnFamilyName, ComparatorType.BYTESTYPE);
cfDef.setKeyValidationClass(ComparatorType.LONGTYPE.getClassName());
cfDef.setComparatorType(ComparatorType.UTF8TYPE);
cfDef.addColumnDefinition(new BasicColumnDefinition() {{
setName(StringSerializer.get().toByteBuffer("id"));
setValidationClass(ComparatorType.LONGTYPE.getClassName());
}});
When I push this exact same application to cloud foundry (our own internal cloud where we have a simple cassandra service), the line above with "addColumnDefinition" results in an exception - here's the stack trace:
java.lang.UnsupportedOperationException
java.util.AbstractList.add(Unknown Source)
java.util.AbstractList.add(Unknown Source)
me.prettyprint.cassandra.service.ThriftCfDef.addColumnDefinition(ThriftCfDef.java:311)
org.pvtl.cassandra.HectorSample.createColumnFamily(HectorSample.java:94)
org.pvtl.cassandra.HectorSample.<init>(HectorSample.java:37)
org.apache.jsp.index_jsp._jspService(index_jsp.java:61)
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:388)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:313)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:260)
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
A bunch of googling and it looks like the trouble is that the Hector code is trying to add to an immutable list - the java.util.AbstractList. But again, that code runs fine on my local tomcat instance so I'm thinking a difference in the jdk? Maybe? I'm running java 7 (sun) locally and pushed choosing java 7. Anyone have any ideas?
Most probably you are using a different version of Hector in your local tomcat than the one in the server (i.e. server has older library) because the immutable list constrain was removed from newer Hector versions
See this pull request discussion
Edit
You might want to check your server configuration and make sure it has the latest hector library and/or check that hector-cor-xxx.jar does not exist under your tomcat/jetty libraries folder as it might cause dependency problem.
I have been trying to deploy my web application (war) from Glassfish AdminConsole but I keep getting the following error message -
Exception while loading the app : Error in linking security policy for MyApp-war -- Inconsistent Module State.
But it deploys without any problem when I do it from Netbeans. (I don't know if Netbeans is doing something that I am missing before deploying the application.)
And I also tried with the latest version of Glassfish (i.e. V3.1.1 (build 12)
), and I can deploy the same application without any problem from AdminConsole.
I am using Glassfish 3.1 (build 43) and Netbeans 7.0.
Is there any Security Policy setting that I have to have before deploying my application with this version of Glassfish?
The same thing was happening to me.
Here is what I did:
Stoped the Glassfish server
Deleted all the content from glassfishhome/glassfish/domains/yourdomainname/generated
Started Glassfish
It worked for me. But what still sucks is that everytime I need to deploy I need to follow this procedure again...
I will answer this in response to the comment of #SteveTaylor. His answer in the above comment helped me solving the problem, so he is the one who deserves the credits.
Original answer from #SteveTaylor:
The problem is a corrupt OSGi cache. The reason upgrading worked for
you is because you started with a clean OSGi cache. All that's needed
to fix this problem is delete the entire OSGi cache under
$GLASSFISH_HOME/glassfish/domains//osgi-cache
This answer worked for me as well. Thanks a lot. I am using a cluster (Oracle GlassFish 3.1.2.2) consisting of two nodes and a domain server. I removed the OSGi cache under all three directories (2 nodes and domain) after I stopped the cluster and restarted it then. After that, the problem was solved.
It happen to me to, especially after I check out different version of my web application and try to deploy it to Glassfish.
The only certain solution I've found is to completely stop galssfish, restart it and deploy the application.
Probably a bug in the version of Glassfish I was using.
Basically changing to a different (later) version solved the problem.
In my case, I was missing #Stateless tag in one of my Managed Beans. Adding it, solved it for me. Hope it helps.
I don't know if this helps, but I got the same error when deploying from the command line. In my case I'm using a pretty up-to-date version (GlassFish Server Open Source Edition 3.1.2 (build 23)). What worked for me was removing --force=true from this:
$ sudo /usr/local/glassfish3/bin/asadmin deploy --force=true ~cornell/designer.war
What's important (I think) is that I had not previously deployed the app. Confusing!
In my case ,just I do "clean and build". that usually works well.
It happen to me too. In my case, it have occurred when I try to deploy the project and forget to start the database server, and then when I start the database server and I deployed again, I got this error message.
When this occurred, I recompile the code, stop the server, undeploy the old project and deploy the new again.
My problem is this exception:
Caused by: <openjpa-2.1.1-r422266:1148538 nonfatal user error> org.apache.openjpa.persistence.ArgumentException: This configuration disallows runtime optimization, but the following listed types were not enhanced at build time or at class load time with a javaagent: "
I'm trying to get an very simple java application with jsf and jpa running, but there seems to be a problem with the enhancement of my entities. As far as I know, tries OpenJPA to enhance my entities at runtime, which are listet in the persistence.xml, however there is no agent to do this. The keyword for this is: Enhancing at Runtime, right?
I thought the enhancement will automatically done by the application server at deployment? How can I configure this?
My exactly environment:
Glassfish 3.1.1
Derby, which is integrated in Glassfish
OpenJPA 2.1.1
Mojarra JSF 2.1.3
Update #1:
After some comments I've added the following lines to my persistence.xml:
<property name="openjpa.DynamicEnhancementAgent" value="false"/>
<property name="openjpa.RuntimeUnenhancedClasses" value="supported" />
It works now, but OpenJPA throw this warning:
SEVERE: 52 myApp WARN [http-thread-pool-8080(5)] openjpa.Enhance - Creating subclass for "[class myApp.model.entities.AbstractEntity, class myApp.model.entities.Post]".
This means that your application will be less efficient and will consume more memory than it would if you ran the OpenJPA enhancer. Additionally, lazy loading will not be available for one-to-one and many-to-one persistent attributes in types using field access; they will be loaded eagerly instead.
I think this can't be the solution.
Update #2:
Refer to fvu's answer, I've tried to define the -javaagent jvm parameter in the domain.xml and over the web admin console. After a restart appeared the problem again.
Update #3:
Refer to update #2, I've played a bit around. There must be thrown an error, when the -javaagent parameter is used, but the file is missing, right?. Yes, there it is:
Waiting for domain1 to start .Command start-domain failed.
Error starting domain domain1.
The server exited prematurely with exit code 1.
Before it died, it produced the following output:
Error occurred during initialization of VM
agent library failed to init: instrument
Error opening zip file or JAR manifest missing : /tmp/openjpa.jar
If I copying the agent to this location, this error doesn't appear, but openjpa could still not enhance my entities!
If you're still having issues... I'd highly recommend biting the bullet and setting up build time enhancement. You'll be much happier in the long run if you get that going.
A couple of ideas:
add the Java agent for enhancement to GF's JVM option, see this link for an example of how to install a javaagent and OpenJPA's doc 5.2.3, enhancing at runtime. That emulates enhancer activation in desktop apps as closely as possible IMO.
However, when I read chapter 5.2.4 of the OpenJPA docs it might be capable of picking up the correct enhancer automatically. Try copying openjpa.jar to the domain's library directory, and check what happens after a server restart.
My application validates a license file in order for it to work. It does this by calling javax.crypto.Cipher.getInstance("DES","SunJCE") inorder to decipher the license key file.
When I run my application locally everything works fine but when I deploy my application with jboss and get to the point where I want to validate the license file on the servlet, I get the following error:
java.lang.SecurityException: JCE cannot authenticate the provider SunJCE
at javax.crypto.Cipher.getInstance(DashoA13*..)
at javax.crypto.Cipher.getInstance(DashoA13*..)
Like I said, it works fine from command prompt and eclipse, but not as a servlet on jboss. Does anybody have any idea what I need to do? I am using jdk 1.6 and jboss as 7.
Thanks
There are a couple of possible issues that come in mind, it seems to be a problem with classpath when sun/oracle jvm try to authenticate provider jars
check that all security jars are under the <jdk_home>/jre/lib/ext of the jvm that runs jboss
(ie US_export_policy.jar, sunjce_provider.jar, local_policy.jar....)
about US_export_policy.jar and local_policy.jar be sure to have downloaded the unrestricted version
java.security file in <jdk_home>/jre/lib/security: be sure to have a line similar to security.provider.X=com.sun.crypto.provider.SunJCE where X is a number
be sure that sunJCE provider jar is not in you WEB-INF/lib
I figured out what was wrong with my code. Earlier in the code for some reason someone did the following:
if (SunJCEinProviders)
{
Security.removeProvider("SunJCE");
}
int i = Security.insertProviderAt(new com.sun.crypto.provider.SunJCE(),1);
So for some reason we were removing javas initial SunJCE provider then adding a new one and this new one was failing to be authenticated.
I have been developing a small project meant to run under weblogic 8.1.
Richfaces according to documentation states that it supports weblogic 8.1.
Weblogic 8.1 uses servlet specification 2.3 with jsp 1.2
This has been working on my locally installed version of weblogic 8.1 but when deploying to the sparc server, I start running into trouble. I have worked through some of the initial headaches, but then I got an error 500 and couldnt get the details. But after some effort I have come out with this...
javax.servlet.ServletException: javax/servlet/jsp/JspContext
at weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:344)
at com.sun.faces.context.ExternalContextImpl.dispatch(ExternalContextImpl.java:346)
at com.sun.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:152)
at org.ajax4jsf.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:108)
at org.ajax4jsf.application.AjaxViewHandler.renderView(AjaxViewHandler.java:216)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:107)
at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:245)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:137)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:214)
at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:1072)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:465)
at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:28)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:141)
at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:281)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:6987)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3892)
at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2766)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:224)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:183)
JspContext is not part of jsp 1.2 it's newer. I am thinking this exception is originally a ClassNotFoundException or something similar considering the message. There is no 'cause' attached to the exception.
Following are the jar files contained in my web-application.
antlr-2.7.6.jar
asm-1.5.3.jar
asm-attrs-1.5.3.jar
cglib-2.1_3.jar
commons-beanutils-1.6.jar
commons-collections-3.2.jar
commons-digester-1.5.jar
commons-lang-2.4.jar
commons-logging-1.0.3.jar
dom4j-1.6.1.jar
ehcache-1.2.3.jar
hibernate-3.2.4.sp1.jar
jsf-api-1.1_02.jar
jsf-impl-1.1_02.jar
jstl-1.0.jar
jta-1.1.jar
log4j-1.2.15.jar
richfaces-api-3.1.6.SR1.jar
richfaces-impl-3.1.6.SR1.jar
richfaces-ui-3.1.6.SR1.jar
xercesImpl-2.9.1.jar
xml-apis-1.3.04.jar
I'm running out of options, I'll be trying to figure out who has the dependency on the JspContext class... but if someone could give me some insight it would be greatly appreciated. Oh, I cannot make many changes to the production web-logic server. I'd prefer not to make any at all, chances are those changes will be denied
Oh this error occurs when attempting to view the page, so deployment is successful.
Ok, I have solved my problem. Not the way I wanted to but it's working (atleast to what I know right now).
After using google (again) I found a comment with someone mentioning using richfaces 3.0.1.
Now I have seen many people say use version xxx even 3.3.x. After all I did get it working with 3.1.6 but on the windows version of weblogic (which could have possibly been tainted by some other weblogic version I have installed).
So I have modified my pom for maven to depend on:
<groupId>org.richfaces</groupId>
<artifactId>richfaces</artifactId>
<version>3.0.1</version>
This is not optimal, but I geuss it works.
Some taglibrary references needed changing, and packages changed to some extent.
I could post my project configuration for this if anyone ever needs it. Getting this all to work on weblogic 8.1 was not straight forward. But the reference documentation for 3.1.6 is to my knowledge incorrect by saying it support weblogic 8.1
jsp-api-2.1.jar contains the missing class, so you could try using it (either replace it in weblogic, or try in your /lib), but I can't predict what would happen.