Develop Reference

Wildfly EAR deployed application location path

My question may sound obvious but i'm quite new working with Wildfly 9 !
I deployed my EAR in server via admin console. My Wildfly is in standalone mode. I couldn't where the ear was deployed ! Is there any specific folder for deployed applications in wildfly ?
Thanks!
[EDIT]
I want to know about deployed location because of class loading in wildfly. I attempted to load a resource which is a .exe from classpasth but it render a wierd path:
Event.class.getResource("/Decorder/Decoder.exe")
I get the following out put in wildfly logs :
C:\apps\wildfly-9.0.2.Final\bin\content\SYSE.ear\SYSE-components-3.0.jar\Decoder\Decoder.exe
I don't know from were the resource path above is coming from !

You have deployed your ear throught the webconsole or cli, it is a managed content and as such is managed through the ContentRepoistory in WildFly. It should be under standalone/data/content + hash part.
This looks quite weird to me : C:\apps\wildfly-9.0.2.Final\bin\content\SYSE.ear

[UPDATED to new question]
This all comes down to how you packaged and configured your deployment.
/Decorder/Decoder.exe might be a valid path if you provided the file in /resources/Decorder/Decoder.exe. This is due to the fact that the classloader will provide all of your resources relative to your root, which in most cases is the jar component.
Note: maybe it is already resolved by removing the typo in your path: /Decorder/Decoder.exe -> /Decoder/Decoder.exe

Websphere 7 classloader differences

I was recently trying to solve class cast exception in our web application. After few tests have found out that the classloader information for our web application right after application server restart are different from classloader information after webapp restart/update (without app server restart).
Classloader information were retrieved using the Manage modules - View Module class loader - Export in the Websphere administration console.
The items (paths to webapp .jar files) in exported XML are the same. But some of the items (as I understand it - these are the classes in webapps' classloader) are different.
Could anybody explain why?
Thanks.
Update:
Here is the difference which is maybe the main problem (I keep getting ClassCastException on XMLSignatureFactory in my log file). This class is contained in xmlsec library and this library is deployed with our webapp war file. The classloader order is set to PARENT LAST, but it seems like sometimes the XMLSignatureFactory from IBM JDK is loaded instead of the xmlsec implementation (after redeploy).
I have described the exception further in this post. After I have changed the settings in MANIFEST.MF file and set up the servlet listener, I could get the application working after every restart, but the redeploy problem still occurs (which is quite annoying).

I got the same problem here. To fix that issue, push xmlsec jar to AppServer\classes then we can override IBM JDK by our lib

2 classes with same name in different jar's in portlet for WebSphere portal

I am working on a portlet project and came across a problem with 2 classes with same name (including packages) in different .jar files. I have com.ibm.ws.webcontainer.jar as a default WebSphere library and jsf-impl.jar which is necessary for some JSF features.
The problem comes out when PortletFacesContextFactoryImpl class (another JSF class) tries to get access to com.sun.faces.util.Util.parameterNonNull(Object arg) method and I get NoSuchMethodError.
I tried setting classloader policy to PARENT_LAST, this doesn't help. I can't remove com.ibm.ws.webcontainer.jar from the server, but when I try to use Util class in my code, the only option is the class from it, not from jsf-impl.jar. jsf-impl.jar is included into Java Build Path.
How can this problem be solved since I cannot alter PortletFacesContextFactoryImpl source and move .jar with wrong class?

Parent Last should be your solution. WebSphere Portal deploys portlet application with Parent Last as default, but it does not hurt to double check it at the WebSphere Application Server Integrated Solutions Console (Admin Console) >
However, it also depends on your portlet application setup. I assume it is com.sun.faces.util.Util which is troubling you. On my system, this class is located in jsf-impl.jar and the Application Server Web Container. In order to get it to work, jsf-impl.jar needs to be placed in the WEB-INF/lib directory of your portlet application. To verify that, use the Class Loader View of WAS: Admin Console > Troubleshooting > Class loader viewer > WebSphere_Portal > Applications and then the your portlet application. It must start with PA. Switch to the table view and search for the class.
You also mentioned the Java Build Path. This is another topic and depends on your IDE - assumingly Eclipse. Check the Order and Export tab, jsf-impl.jar should be placed at the top, so that it overrules the server runtime classpath entries.

PARENT_LAST classpath setting will help you. However, for this setting to be done, your portlet muste be packaged as a EAR. If your portlet is packaged as a war and you configure the classpath settings manually, they get erased everytime you deploy the portlet.

Exception Thrown java.lang.NoClassDefFoundError: org.apache.commons.logging.Logfactory from Domino OSGi Plugin

I am building an IBM Domino OSGi plugin which packages up a class that entends HttpServlet.
I want to make Http calls (get, post, etc.) from the Servlet using org.apache.httpcomponents.httpclient_4.2.3 and org.apache.httpcomponents.httpcore_4.2.3 (extracted from the OSGi bundles).
I have added the two jar files to domino\jvm\lib\ext, made the usual changes to java.policy file*, and added the jars to the build path.
When I add code to create and use DefaultHttpClient the server throws the error:
java.lang.NoClassDefFoundError: org.apache.commons.logging.Logfactory
I know that logging is a bit of a tricky subject in Domino's java implementation. The curious thing is I have the same code running with a Servlet contained by an NSF which runs just fine. However within my OSGi context it breaks. If I call the servlet using a url that includes say /log.nsf/ it still breaks.
Any help gratefully received!
grant {
permission java.security.AllPermission;
};

I'm not sure why it works in your NSF implementation but looks like you need commons-logging-1.1.1.jar. That should be included in the httpcomponents download. Or you can download it from here:
http://commons.apache.org/logging/download_logging.cgi

I've had problems with org.apache packages before in XPages, basically because they try to log to the file system and the security policy doesn't like that. Adding it as a referenced library etc, it uses the same ClassLoader as the XPages runtime, so tries to use the one from the server, and that's when you get the NoClassDefFoundError.
Tried adding it to the WebContent\WEB-INF\lib folder of your OSGi plugin. Adding it to that path works in an NSF because it uses a different ClassLoader. It could well circumvent the problems you're having in an OSGi plugin as well.

Tomcat deployment of grails war having classpath issues

I am deploying a WAR into a Tomcat 6 or Tomcat 7 server on a Windows 2003 Server box. The error looks something like
java.lang.Exception: Error initializing iSec web service proxy: Unable to create JAXBContext for generated packages: "com.integrity_apps" doesnt contain ObjectFactory.class or jaxb.index.
which I was getting previously when tools.jar was not in the classpath of my application. I was running the grails app from STS with the default web container, and I was able to fix this by re-installing JUST the JDK with tools.jar in the lib dir, and making sure JAVA_HOME was set correctly.
I have tried the same steps on the server - only installing the JDK, making sure JAVA_HOME is pointing to it, and dropping my WAR in the Tomcat container. I am still getting the error. Can anyone suggest why this may be happening?
As a further datapoint, I have noticed that if, on the server, I run the Tomcat7.exe from the command prompt directly (JAVA_HOME is set as a system variable), the error goes away. If I run it from the service manager, the error comes back.
Thanks

Looks like "com.integrity_apps" is your package containing your JAXB bean classes? I think it's missing ObjectFactory class within the package.
Check if there is a package called "com.integrity_apps" and if there is a class named ObjectFactory in that package. If not you may want to add it or use other ways to let JAXBContext know how to create your JAXB beans. This question on SO may be helpful:
Do you always need an ObjectFactory class when using JAXB?