It looks like you are using your own logging framework which might be causing the logger to suppress WildFly logging.
I am suspecting this because i see timestamps format changing for the logging as "[2015-11-23 11:15:38,965]" then "11:15:39,086" , So i am suspecting that some kind of logging inside your application might be causing the logger to not to display the further logging.
Also it will be best if you can share some more information about your WAR like:
1. What kind of framework does it use?
2. What kind of JARs are included inside it. I mean sharing the list of JARs present in the "syme-war-1.0.0-SNAPSHOT/WEB-INF/lib" will help much in this case.
3. What kind of logging are you using in your application and the logging related configs.
4. Also your application says "Artifact syme-war:war exploded: Artifact is deployed successfully" what does it mean, What does it explode and in which directory ?
I think Weblogic uses another word for the same action and you should just replace the word 'start' with 'enable' when thinking in WildFly terms. Both words define the same.
The first step is to deploy (or install) the application. But before i can be used the application must be enabled (or started).
Thank you for taking the time to look into this. I hadn't thought of the logging angle. I am using log4j for logging.I do have commons-logging jar included but that is coming as a dependency. I also see slf4j which would also be coming as a dependency to other jars. A copy of my log4j.properties is attached. I verified that my log levels are set to debug so not sure what else I can do there. Let me know of any suggestions for not conflicting with wildfly logging. I'd like to continue using log4j if possible. I would think many jboss users are using it. I'll check the forum for other log4j issues. (#3)
The primary frameworks I am using are Spring, Jersey and eclipseLink. (#1)
The exploded war is used by intellij. eclipse uses something very similar. I believe it is something that is integrated with wildfly to run applications from the IDE and support updated code. I am attaching a copy of "syme_war_exploded.xml". It refers back to a snapshot war as well as the lib and classes directory in my project target directory. It also has a list of all the jars it is using (#2 & #4).
Again, thanks for looking into this. My workplace seems to be more open to making a move from weblogic and wildfly looks like a very viable replacement. The savings in startup time alone will increase our developer productivity.
The runtime-name needs to have a ".war" extension on it so it's processed as a WAR. I wouldn't worry too much about the logging output difference as I suspect some of this is WildFly logging and some of this is Intellij logging.
James R. Perkins
I've gotten a bit farther but still not starting up. I'm attacking the problem on several fronts. I got rid of my log4j.properties and marked my log4j jar in maven as source provided. That didn't seem to have much effect.I don't know if the intellij/wildfly startup is just not doing anything or if it is that it is failing while it is enabling and simply not giving me information in the log.
I did find the server.log which I didn't see before. It looked pretty much the same as my console. So I generated a war file and was able to enable that. I saw that I had some errors with my datasource which I fixed. I do see that the intellij/wildfly startup is correctly seeing the datasource. Now getting other spring errors which appear to be related to finding the correct class for load time weaving. (I actually dont need that at this point.)
2015-11-27 13:58:50,858 ERROR [stderr] (MSC service thread 1-13) [ModuleClassLoader@2ab8fd7e] error can't determine implemented interfaces of missing type org.osgi.framework.SynchronousBundleListener
2015-11-27 13:58:50,859 ERROR [stderr] (MSC service thread 1-13) when weaving type com.sun.jersey.core.reflection.ReflectionHelper
2015-11-27 13:58:50,860 ERROR [stderr] (MSC service thread 1-13) when weaving classes
2015-11-27 13:58:50,860 ERROR [stderr] (MSC service thread 1-13) when weaving
2015-11-27 13:58:50,861 ERROR [stderr] (MSC service thread 1-13) [Xlint:cantFindType]
I am attaching my application context file and a couple of log files.
(At some point I would like to move from Spring to JavaEE but I have a fair amount of experience using Spring and not too much with JavaEE so I think that might take me down a whole new road of unknown problems if I try that now.)
So there are two things I need to get working. First, fix the ModuleClassLoader error that I see in the startup from the war. Second, being able to run the app from within intellij.
Your latest error is :
2015-11-27 13:21:37,471 ERROR [org.springframework.web.context.ContextLoader] (MSC service thread 1-13) Context initialization failed: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'symeEntityManagerFactory' defined in URL [vfs:/C:/apps/wildfly-8.0.0.Final/bin/content/syme-war-1.0.0-SNAPSHOT.war/WEB-INF/lib/syme-domain-1.0.0-SNAPSHOT.jar/META-INF/symeApplicationContext.xml]: Cannot resolve reference to bean 'cmtDS' while setting bean property 'dataSource'; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'cmtDS': Invocation of init method failed; nested exception is javax.naming.NameNotFoundException: jboss/datasource/ExampleDS -- service jboss.naming.context.java.jboss.datasource.ExampleDS at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveReference(BeanDefinitionValueResolver.java:329) [spring-beans-3.1.4.RELEASE.jar:3.1.4.RELEASE] . Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'cmtDS': Invocation of init method failed; nested exception is javax.naming.NameNotFoundException: jboss/datasource/ExampleDS -- service jboss.naming.context.java.jboss.datasource.ExampleDS . Caused by: javax.naming.NameNotFoundException: jboss/datasource/ExampleDS -- service jboss.naming.context.java.jboss.datasource.ExampleDS
Can you please check if the default dataSource ExampleDS which has the JNDI name "java:jboss/datasources/ExampleDS" is present on your WildFly profile which you are running or it is mistakenly removed ?
By default the ExampleDS is present in all the WildFly 8 profile (standalone*.xml/domain.xml)and on startup it shows the following message in the log, But this message is not appearing in your server.log which indicates that some one removed the ExampleDS which your application 1s looking out for.
[org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) JBAS010400: Bound data source [java:jboss/datasources/ExampleDS]
Sorry, I sent the wrong log. Actually what I sent was a complete log from a bunch of startups. At 13:21 I was still getting the datasource error for cmtDS. Later, I changed my cmtDS data source to use the ExampleDS data source that is present in the Wildfly environment to get past the datasource error. If you go to the startup starting at 13:58:39,243 (which i will attach in a separate file) you can see that I got past that and was getting the Spring load weaving error at 13:58:50,858,
Another thing I plan to do is find one of the example JavaEE projects that are mentioned in the wildfly/intellij video and see if I can deploy/enable that from intellij. If so, I can build on that. It still is unclear to me if my intellij deployment is failing without my knowing it due to lack of logging or if it is never getting that far.
Again, thanks for your time.
server.log.springError.zip 2.3 KB
It's tough to say what's going on in there. log4j is definitely being used, but that's not really an issue. I see references to Jersey too which is not the JAX-RS implementation used by WildFly. If I had to make a guess it looks like you're missing some OSGi library that includes org.osgi.framework.SynchronousBundleListener.
James R. Perkins
Just wanted to let you know where I was at on this. Rather than pursue multiple issues, I had the flexibility to start with a smaller app and add in external frameworks one at a time to see where problems might occur. The current app is starting ok. I'm switching from Spring to JEE so hopefully that will simplify things. I do have some issues with log4j for which I will open a separate post. Thanks for your time looking at this.