I have jsf webapp. I have successfully deployed it to Cloudbees using steps from http://blogs.jetbrains.com/idea/2012/12/deploy-web-apps-to-cloudbees-from-intellij-idea-12/.
The problem is that the app won't work until I change the ClickStack to web application profile. The default one is Tomcat. My change is always lost each time I deploy/update the app from IntelliJ Idea. Deploying the app from PaaS console works without problem.
Is there any setting to make the Idea plugin remember the used stack?
It appears to be a bug, reported in YouTrack, star/vote the issue to receive notifications.
Found a work around. Include a jsf implementation to the app.
Support for ClickStacks had been added to IDEA CB integration, staring from next IDEA 13 EAP, it will be possible to choose between "Basic Java Webapp (Tomcat)" and "Java EE 6 Web Profile (JBoss)" options.
Related
On SAP Web IDE Multi-Cloud version, when right clicking and going to Run > Run as > Web Application or SAP Fiori Launchpad Sandbox it gets to the SAML authentication and that stops on a white screen, with no errors in the console log.
I've tried this on custom apps I've created and also a new SAPUI5 app from template, nothing works. It only works if I deploy it to the SAP Cloud Platform then register it to my personal Fiori Launchpad.
I've tried the exact same in the standard SAP Web IDE version (non- Multi-Cloud version) and it works.
If anyone knows the solution to this, it would be great.
Thanks
Issue resolved. Turns out the destinations 'webide_di' & 'webide_di_s2s' should be created automatically when you enable the SAP Web IDE Multi Cloud Version service, but in my case they were not. Once I added them manually, it started working.
I'd need to know if it's possible to setup a management user for the JBoss (AS7 and WildFly) which is valid just for the CLI (and not for the Web console).
Thanks
I'm afraid you can't since the CLI and the Web Console use the same API. Since also both may do the same stuff I don't see what you are trying to achieve.
Afternoon All,
Here is my context:
I am setting up an existing worklight project with App Envs for IPhone, Android, and Mobile Web.
When using the Worklight Console to preview the apps, I get context root errors from the iPhone app only. (I get the Error: The Server was unable to process the request from the appl...)
When I open the browsers JS console, I see the problem is that the app is requesting the wrong context root. It is accessing the /worklight/ context, which is not there.
The contextroot that does work is the following:
http://localhost:8080/apps/services/api/[APPNAME]/iphone/init
The Context root that the iphone is trying to hit:
http://localhost:8080/worklight/apps/services/api/[APPNAME]/iphone/init
Here is the weird part. The context root is fine for the Android, and Mobile Web environments. Only the iPhone environment is having context root issues.
All three environments are sharing the same application-descriptor.xml file and same server.
Below are some file outputs.
Files below:
/server/conf/worklight.properties
publicWorkLightHostname=localhost
publicWorkLightProtocol=http
publicWorkLightPort=8080
publicWorkLightContext=/worklight/
/apps/[APPNAME]/application-descriptor.xml
<worklightServerRootURL>http://localhost:8080</worklightServerRootURL>
So a couple of questions.
1) When setting the context roots, what is the relationship between the client and server. Do the context roots have to match between the two? Is one a master and the other simply slaves from that and does not need settings?
2) (Somewhat unrelated) While debugging this issue I have come across zero documentation about how to go about "un-deploying" the server in the Eclipse dev ide. (un-deploy the server is right from IBM's documentation) I need to know how to redeploy the server when I make changes to the server settings (worklight.properties). I have seen references to cracking open the war manually, to just stopping and starting the server in the IDE.
Any help is greatly appreciated.
If you are using a context root, it must exist in both worklight.properties and application-descriptor.xml. make sure both match, then re-build and deploy and see if the problem persists.
When using the development edition of Worklight, your server is based on Jetty which is run within Eclipse (it is bundled with the Worklight Studio plug-in you have installed in Eclipse). You do not need to "undeploy" anything. Simply make the changes to worklight.properties and application-descriptor.xml and re-build your application. The changes will make their way to both the server and client.
Do note, though, that using a context root is mainly for when using application servers such as Tomcat, Liberty or WAS.
Is there a straight forward approach for JBoss AS to print messages to the console in eclipse? I intend to use them only for debugging purposes and nothing more (I swear).
I'm new to JBoss and I don't know where to start and what to do to get my System.out.println()-messages appear in the console.
Unfortunately I have been struggling too long for today to achieve this rather natural requirement. I'm using JBoss AS 7.1.
edit:
Ok, looks like this time the problem is sitting in front of the screen. I couldn't find my logging even in the server.log. The reason is that the code which I was executing throwed an error which prevented the sysouts from being printed to the console. I'm sorry. Thank you for your help.
If you make a Sysout in your application, you can find it at the server.log, inside the folder $JBOSS_HOME/standalone/log
That, however, is not the best practice, since there's a lot of configuration and possibility at the log. You can check more information about that here
But, if you just say System.out.println('hello world') it will be out at server.log
All logging after the boot is made there so there you can check your System.out.println() stuff
With a default install a console handler and a file handler are configured. If you want to log to either you just need to use a logger. Printing to System.out or System.err it will work as well, but I would suggest using a logging facade like JBoss Logging, SLF4J or even just J.U.L.
If you're wanting to run JBoss AS inside eclipse the easiest way is to use JBoss Tools. You can start, stop and deploy your application from within eclipse locally for testing.
In my project I had 2 log4j.proprties files one is provided by jboss other is in my workspace. I removed one log4j.properties file now I am able to see sysout on the console.
This is with GF 3.1.1 build 12.
I have a JSF 2 web application that uses EclipseLink 2.3.0 as the back end JPA provider. You can see the deployment here.
When I use the admin console to redeploy, it uploads the WAR file just fine, then all hell breaks loose. As soon as someone accesses a page the log fills with exceptions usually related to attempting to do operations on a closed EntityManager. If I let it go on, GlassFish degenerates and pretty much crashes -- I can't get any response anymore on the admin port.
If I do a reload, then it seems to work OK. So my question is, what kind of application can do a redeploy without a reload? Is there something I can do to my application to let do a smooth transition from one version to the next?