Running in Websphere Portal 7 and MyFaces 2.1.10.
The deployment descriptor for the web module in WAS shows the PROJECT_STAGE property has a value of 'Production'.
Yet when the application starts I see the MyFaces warning "Apache MyFaces-2 is running in DEVELOPMENT mode". If an error occurs in JSF I see the full stack trace on the page which indicates that it is in fact running in DEV mode.
Can the property be set somewhere else which overrides the value in the web.xml file? How can I stop DEV mode if the value in web.xml seems to be ignored?
Thanks.
I had setup JRebel on this project and it turns on facelet DEVELOPMENT mode. http://zeroturnaround.com/software/jrebel/features/frameworks/
Related
I had been using Grails 3.3.2 for about 3-4 years now and never had this issue. I just recently started migrating our apps to Grails 5 and now this started happening. Everytime I save a change to a file (gson, groovy, etc) the app redeploys and I have to wait a good 5-6 seconds before I can test it (url becomes available).
In Grails 5 my console looks like this when I make changes:
Grails application running at http://localhost:8081 in environment: development
File C:\Workspaces\Intellij\ecpp\grails-app\controllers\ecpp\service\LookupSvcController.groovy changed, recompiling...
Grails application running at http://localhost:8081 in environment: development
File C:\Workspaces\Intellij\ecpp\grails-app\controllers\ecpp\service\LookupSvcController.groovy changed, recompiling...
Grails application running at http://localhost:8081 in environment: development
File C:\Workspaces\Intellij\ecpp\grails-app\controllers\ecpp\service\LookupSvcController.groovy changed, recompiling...
Grails application running at http://localhost:8081 in environment: development
Each one of those Grails application running [...] lines is a 5+ second delay I have to wait through before the app comes back up
When I would work on my 3.3.2 projects my console would look like this during changes
Grails application running at http://localhost:8081 in environment: development
File C:\Workspaces\Intellij\ecpp\grails-app\controllers\ecpp\service\LookupSvcController.groovy changed, recompiling...
File C:\Workspaces\Intellij\ecpp\grails-app\controllers\ecpp\service\LookupSvcController.groovy changed, recompiling...
File C:\Workspaces\Intellij\ecpp\grails-app\controllers\ecpp\service\LookupSvcController.groovy changed, recompiling...
I never had to wait, I could immediately refresh the page and see the changes. Needless to say, my DEV time has taken a hit having to stop and wait for a redeploy. Is there some configuration I missed while upgrading that I can set to resolve this?
This happens while running the app with gradlew bootRun as well as grailsw run-app
Grails 5.1.7
JDK: 11.0.13
I just recently started migrating our apps to Grails 5 and now this
started happening. Everytime I save a change to a file (gson, groovy,
etc) the app redeploys and I have to wait a good 5-6 seconds before I
can test it (url becomes available).
The behavior you described is expected and by design.
Older versions of Grails were configured by default with a reloading agent. Grails 5 is not. The default behavior you will get with Grails 5 is a recompile and restart. If you don't want that behavior you can remove the devtools from your build.
You didn't ask about configuring a reloading agent but if you are interested, see the Spring Boot Developer Tools and Spring Loaded section at https://docs.grails.org/5.1.7/guide/single.html#upgrading33x.
I have run into a very serious problem where I can longer deploy a war of a Grails 2.2.5 web application on Tomcat. The build (with 'grails war') proceeds without a problem, and I deploy it to Tomcat. I retsart Tomcat, and the web application simply does not run. It comes up with the deploying message, but clearly doesn't get as far as running Bootstrap.groovy, because logging from there doesn't show up in the log. No error messages are given, but the web app is simply not running.
I ran into a similar problem a few days ago on a different server which I solved by upgrading to Tomcat 7, but this one is already running Tomcat 7. I have no idea why this has started happening, unless it is something obscure to do with the recent change in Maven where only TLS 1.2 connections are allowed (a change which occurred a week or so ago).
So what could be happening? Is there some way I can log what is happening as the web app starts up, such that I might be able to see where the problem is occurring?
If it is of any relevance, it works OK when I do 'grails run-war' on my development machine.
The Grails system with which we've been working fine for several months now has a problem whereby the /login/auth page appears blank.
The problem with the build only occurs on a deployed Tomcat or standalone system and not on local development machines where it works fine. There is no error appearing on the console at all.
The Network tab in Chrome shows a 404 error. We've put console debug messages in the auth() method within LoginController and these are not showing up.
In intellij Idea works fine, after generate the .war file (./gradlew assemble) the system not work.
If you get an 404 error, you should check all of the config files e.g. database settings. Somewhere must be a difference in those settings. Usually it is database connection which causes such kind of errors.
You can also check Catalina.log in the Tomcat server directory to find errors.
I'm trying to debug worklight 6.1 adapter code (java). I figured the most logical way would be to restart the imbedded liberty server in debug mode. That fails with a message:
ERROR: Cannot load this JVM TI agent twice, check your java command line for duplicate jdwp options.
Error occurred during initialization of VM
agent library failed to init: jdwp
I followed the process documented for 6.0 at Logging and debugging Java on Worklight Server but I get the same issue there.
Ok, this is silly, but I just figured it out. You do not need to set anything for debug mode. Apparently in 6.1 this is already set. To begin debugging of your java code in the adapter you need to do the following:
Create a debug configuration for a "Remote Java Application".
Set the project to your worklight hybrid project
I set the port to 10777. which is what jdwp was set to in the jvm.options file for the worklight server.
Once you click on debug for that configuration, it will allow you to debug your adapter.
You can see the jvm.options file if you expand the Worklight Development Server definition in the Servers view. See below for an example of the contents of that file.
-Dfile.encoding=UTF-8
-Duser.language=en
-Duser.country=US
-Djava.awt.headless=true
-Dwas.debug.mode=true
-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=10777
-Dcom.ibm.websphere.ras.inject.at.transform=true
Uploaded video to youtube on how to do this
Issue on Websphere 6.1 I hope I'm missing something obvious: We have an application which gets deployed to a configured Websphere environment. We're trying to mimic this WebSphere configuration on a different platform (Linux vs Solaris), but maybe we're missing some obvious settings. The application deploys and starts without an error, but after logon on url localhost:port/app/index.jsp
(via j_spring_security_check) Websphere redirects to localhost:port/index.jsp. This gives an JSP processing Error (HTTPError 404), with code JSPG0036E.
The webapplication is wrapped in an ear, because those are the standards here. And that ear works well on our solaris WAS 6.1 environment but not on the linux WAS. Furthermore in development we've the wrapped war running on Tomcat without problem.
I think I missed the context root somewhere but It's not to be found in Websphere's console, I wouldn't be surprised if it is a Websphere (6.1.0.33) Bug, hopefully I'm wrong or are there workarounds?