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.
Related
I have recently installed the WebLogic 12.1.3 on my local windows 10 desktop. Created a very small webapp and it ran fine until I added the beans.xml.
Adding the beans.xml and starting the server, I get the error : weblogic.management.DeploymentException: java.lang.NoSuchMethodError: com.sun.faces.util.Util.isCdiOneOneOrGreater()Z
I could sort of understand it is something related to a mismatch in JSF versions. Then, I started searching and stumbled upon this beautiful answer from BalusC.
How to find out the current version of Mojarra which my WebLogic is using?
The above answer says "Another way would be to explore the JSF module in /wlserver/modules folder of WebLogic installation. In my 12c installation, the filename says glassfish.jsf_1.0.0.0_2-1-20.jar, which in turn identifies Mojarra 2.1.20".
So I checked to see what is there in my modules folder and I got more than 1 jsf jar. My question (preferably to BalusC :-) but also to anyone who can help) is
- if it is fine or not to have multiple JSF related jars in the modules folder.
- if this multiple JSF jars is the reason for the error ?
- if I can clean up (manually delete) files in this "modules" folder to have one version of JSF related files ?
Note : All these stuff came out of the box with the 12.1.3 installation.
JSF related files found in my "\wlserver\modules" folder
glassfish.jsf_1.2.0.0_1-2-15.jar
glassfish.jsf_2.0.0.0_2-1-20.jar
javax.jsf_1.4.0.0_1-2.jar
weblogic.server.modules.jsf_12.1.3.0.jar
weblogic.server.modules.jsf2.0_12.1.3.0.jar
weblogic.server.merge.modules_12.1.3.0.xml
weblogic.server.modules.extra_12.1.3.0.xml
weblogic.server.modules.jsf_12.1.3.0.xml
weblogic.server.modules.jsf2.0_12.1.3.0.xml
Thanks a lot in advance.
Using JSF and JSTL With Web Applications:
https://docs.oracle.com/middleware/1213/wls/WBAPP/configurejsfandjtsl.htm#WBAPP197
it will depend if you are embedding the JSF jar's.
I think you need to upgrade JSF, embedding the jars and using Filtering Classloading.
<prefer-application-packages>
<package-name>javax.faces.*</package-name>
<package-name>com.sun.faces.*</package-name>
<package-name>com.bea.faces.*</package-name>
</prefer-application-packages>
<prefer-application-resources>
<resource-name>javax.faces.*</resource-name>
<resource-name>com.sun.faces.*</resource-name>
<resource-name>com.bea.faces.*</resource-name>
<resource-name>META-INF/services/javax.servlet.ServletContainerInitializer</resource-name>
<resource-name>META-INF/services/com.sun.faces.*</resource-name>
</prefer-application-resources>
It looks similar (jboss) to: java.lang.NoSuchMethodError: com.sun.faces.util.Util.isCdiOneOneOrGreater()Z
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
I have a XPage application where I use JavaMail in one of my managed beans. Currently I have added the jar-file C:\Programme\IBM\Notes\framework\shared\eclipse\plugins\com.ibm.designer.lib.javamail_9.0.0.20130301-1431\lib\mail.jarto the build-path of the manged bean. This works well. But now I want to use a newer version of JavaMail as the Domino server uses version 1.3 but I need version 1.4.x.
I have downloaded the new JavaMail jar-files from Oracle. In Domino Designer (version 9) I add this jar-file to the new design element "Code / Jars" and remove the old jar-files from the build path.
My managed bean is still compiling and running as desired, but if I check the version the bean is using it reports still version 1.3. To check the version number I use the debug property of JavaMail and it's reporting version 1.3 to the domino server console.
Is there a way to tell the domino server to use the jar-files in the application (i.e. the nsf) and not his own? Is there another approach to update the JavaMail version?
The reason I want to use a newer version of JavaMail is as follows: I want to read mails from an imap server with ssl. To avoid the problem of importing ssl-certificates I simply want to trust all hosts. This can be be done via MailSSLSocketFactory, but this is only available since version 1.4.2. Therefore I want to use a newer version of JavaMail.
Another reason I want to use a newer version is as follows: the method "getSortedMessages" of "IMAPFolder" is only available since version 1.4.4. (and so are some other features of JavaMail).
This may be a little too late for you... I think the right approach may be to include the jar file as an OSGi plugin.
I have spent some time to figure out how to do that - and recently succeeded :-) I have described the steps to perform to make this work in two articles. The first is about wrapping a JAR into a plug-in: http://www.dalsgaard-data.eu/blog/wrap-an-existing-jar-file-into-a-plug-in/ - the second is about deployment (and there is a link in the first one).
/John
You can solve the problem by creating an OSGi plug-in that supersedes the one that sports the JavaMail library: com.ibm.designer.lib.javamail.
In order to do that do the following:
Create an OSGi plugin whose id is com.ibm.designer.lib.javamail (Dalsgaard's tutorial on how to do it)
Set its version to a higher number than the one the Domino server is shipped with (to know the version type tell http osgi ss com.ibm.designer.lib.javamail). As of now using 9.0.1.qualifier should be fine
Deploy the plugin either through an update site or by directly copying it under the domino\workspace\applications\eclipse\plugins folder.
Restart the HTTP service. The higher version - the one you created - will now be used
I've got the same problem here, but found a solution. Be warned, this is not the best answer but it will work. Simply download the latest javamail jar here and rename the jar file to 'mail.jar'. Just replace the current file in IBM\Notes\framework\shared\eclipse\plugins\com.ibm.designer.lib.javamail_9.0.0.20130301-1431\lib\mail.jar with this file. Quit the http task and restart it. The code will now work with the latest version.
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.
I am trying to deploy the Liferay portal onto the Eclipse Virgo Web Server and haven't had much luck. I have at least solved two of the problems involved in this process:
1) The portal.jar that is part of the liferay dependencies has a malformed manifest. The Bundle-SymbolicName incorrectly sets the value to "JSR 286" when it should be "JSR286" (no space). Also, the Import-Package has a bunch of spaces/tabs and I removed those. That took care of problem 1.
2) The Virgo web server wasn't finding the liferay dependency jars (at least not where I was putting them), so I just stuck the dependencies into the main liferay.WAR and that has gotten rid of all the error messages.
Unfortunately, this didn't solve the overall problem. Perhaps there are other issues, but Virgo is not reporting any errors.
I've looked on both the Liferay and Virgo forums, but no one seems to have an answer to this, so I'm hoping someone here has had more success than me. If so, please let me know what you tried to get it to work.
A little more detail: I used the liferay-portal-6.0.5 WAR that is not bundled with an app server. And, I'm using Virgo 2.1.0.
Thanks,
David
I got it! http://sourceforge.net/projects/liferayforvirgo. But Virgo 3.6.0.RELEASE demonstrates too low performance and the couple Liferay+Virgo is not able to use for production