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.
Related
docdokuplm
Hi !
Just checking out your PLM, looks great! I followed your instructions:
https://github.com/docdoku/docdoku-plm/wiki/Installation-Guide
I used the nightly build.
After uploading the ear file and then using http://localhost:8080 I see the Payara server page. Was there something else I need todo or where do I start to troubleshoot? Thoughts?
Thank you!
The page displayed at 8080 is the default landing page. If you have deployed the DocDokuPLM application and configured the settings detailed within the instructions, you can open the application through Payara Server. Go to Applications -> DocDokuPLM -> Launch, and you'll get a series of links which should help you troubleshoot.
If you can't see any, run through the installation procedure again to ensure that you haven't missed a step - it seems like there's a few steps which must be configured exactly correctly for the application to work.
According to this GitHub issue, this seems like a bug with DocDokuPLM. As with most software, nightly builds are inherently risky. Looking at the source, though, it seems that the code changes fairly rarely, so you might try with the previous version of Payara Server (173), though the stack traces in the GitHub issue don't look to me like an issue with Payara.
The backend server and the UI are two separated components.
If you want to install the User Interface you have to go there :
https://github.com/docdoku/docdoku-web-front
The project which you have deployed is just for backend,inorder to interact with UI just clone the web-client from this repo https://github.com/docdoku/docdoku-web-front and in command prompt use this command npm run dev then you can use this project, make sure the port number which is mentioned in app/webapp.properties.json of web-client project is same as you have given in server-config.
Read https://github.com/docdoku/docdoku-web-front/wiki/Development-Guide for more details
I have created a foxx app for a mobile app I am working on. But, the URL's I have exposed sometimes work correctly but sometimes they fail with following response:
{"error":true,"code":404,"errorNum":404,"errorMessage":"unknown path 'contactspace/initiateRegistration'"}
I did not face this issue when I tested the app in dev environment.
I am not able to figure the reason for the issue. How can I debug the problem ?
Thanks,
Vikas Tandi
I can finally confirm it was a problem that had nothing to do with the actual code of your Foxx application.
We have been struggling to reproduce the issue for quite a while, but were able to do so and fix the problem today.
A fix for this has been pushed in the 2.3, 2.4 and devel branches, and will be shipped with ArangoDB 2.3.5, 2.4.1 and 2.5.
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
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.
I have a problem with IIS 6.0 ceasing to work for an ASP.NET application after installing Service Pack 1 for .NET 3.5.
I have 2 identical virtual dedicated servers. Installing SP1 on the first had no adverse effect. Installing it on the second caused ASP.NET pages to start returning 404 page not found.
Static .html pages working okay on both servers.
Has anybody else experienced this?
This is broad problem, so let's start by asking some troubleshooting questions:
Based on your description, the ASP.NET runtime is not catching your request and processing the aspx files. You may need to register the asp.net pipeline with IIS again using ASPNET_REGIIS -i.
Have you made sure that the app_offline.htm file has been removed
from the directory of the application?
I have had this happen before after an
update.
Have you setup fiddler for instance to follow the request to see what is
exactly being requested?
Make sure ASP.NET is enabled in the IIS Administration Console under "Web
Service Extensions." Make sure everything is set to allowed for your different versions of the framework.
Well, let's start with those and hopefully we can guide you to the problem.
I've seen various people with this problem recently. This link might help.
And this one.
And a few others.
Is CustomErrors in your web.config set to On or RemoteOnly? If so, what do you get when you change it to Off?
I have not had this exact error with .NET 3.5 SP1, but have seen similar occur in the past. Typically it can be resolved by opening a command prompt, going to the appropriate .NET folder and running ASPNET_REGIIS -i. In the case of .NET 3.5 there wasn't an update to the main bits of the framework, so you'd actually go to the .NET 2.0 folder, which on my machine can be found at:
\Windows\Microsoft.Net\framework\v2.0.50727
Running the ASPNET_REGIIS -i will re-register all the ASP.NET libraries with IIS, and should be the equivalent of a re-install of the framework on a given machine (as far as IIS is concerned)
Just to clarify. The last (4th) point given by Dale was the problem. During the installation of SP1 the Status for ASP.NET and WebDAV became set to Prohibited under Web Service Extensions.
Why the installation of SP1 changed this setting on one server and not the other is a mystery that I wouldn't mind (but not expect) an answer to...
The second link provided by CodingTheWheel also had the answer so I'm also going to mark this as an answer.
No-one did before, so I'll point to the trivial solution:
Have you already de-installed the Service Pack and re-installed it again (or the whole framework)?
Edit: #Kev:
Easy explanation: He said the update works on one machine, but not on the other. I had similar problems in the past and re-installing helped to solve some of them. And it is trivial to do.
That's my approach:
1. trivial
2. easy
3. headache
You are right, on productive systems you must be careful, but that's his decision. And because it is a virtual server, maybe it is easy for him to copy it and try as a test environment first.