SLF4J: Class path contains multiple SLF4J bindings during WSO2 IS startup - wso2-identity-server

One of my WSO2 IS (Identity Server) went poof due to physical host error, and when I want to bring back up the IS service, it just hangs and won't start up right after these warning message:
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [bundleresource://539.fwk120694604:1/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/usr/lib64/wso2/wso2is/5.6.0/repository/deployment/server/webapps/api%23identity%23entitlement/WEB-INF/lib/slf4j-simple-1.6.1.jar!/org/slf4j/impl/StaticLoggerBinder.class]
Aside of IS process hanging, there is no logs generated as well, so as per the warning messages said, there are conflicting logging classes for WSO2 IS, but I can't find this class whereabout:
bundleresource://539.fwk120694604:1/org/slf4j/impl/StaticLoggerBinder.class
My current WSO2 IS version is 5.6.0 and due to some restriction I can't upgrade the version and I don't think versioning is the issue here.
I had search all over the internet but mostly involve edit pom / maven kinda stuffs but WSO2 IS is supposed to be ready product right? Well, thus until now I still can't find any solution.
Can any kind soul help me with this issue?
Thank you.

This is thrown as a warn in WSO2IS
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [bundleresource://540.fwk1316864772:1/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/home/maneesha/WSO2/Stackoverflow/wso2is-5.6.0/wso2is-5.6.0/repository/deployment/server/webapps/api%23identity%23entitlement/WEB-INF/lib/slf4j-simple-1.6.1.jar!/org/slf4j/impl/StaticLoggerBinder.class]
This happens because there is an SLF4J jar file in
<IS-HOME>/repository/components/plugins/slf4j.log4j12_1.6.1.jar
<IS-HOME>/repository/deployment/server/webapps/api#identity#entitlement/WEB-INF/lib/slf4j-simple-1.6.1.jar
both contain the StaticLoggerBinder.class this could have been avoided using dependency management while building the api#identity#entitlement.war file.
https://github.com/wso2/carbon-identity-framework/blob/ed3e0a150adb8363f2bbd7f91a249b66c069a992/components/entitlement/org.wso2.carbon.identity.entitlement.endpoint/pom.xml#L85
As you can see there is no scope provided, can use the below dependency management to make the SLF4J lib not to bundled into api#identity#entitlement.war file
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-simple</artifactId>
<scope>provided</scope>
</dependency>

Related

Add servlet in a clojure ring project

I am integrating Togglz library into a Clojure Ring project to support feature toggles and would like to activate the Togglz admin console. According to the Togglz documentation it is necessary to add a servlet in the /WEB-INF/web.xml file for projects that don't support Servlet 3.0. I used the :uberjar-merge-with leiningen plugin to merge the file with the Togglz servlet configuration with the web.xml file autogenerated by leiningen. However, this was not sufficient to activate the admin console.
I could not find much information on how to integrate a servlet from an external library into a Ring application. What would be the best way to do it?
I have not tried it myself, but the lein-servlet library seems to promise to do exactly that

dropwizard and jetty-config files

Where do I have to put jetty specific configurations in dropwizard, such as
jetty-context.xml
jetty-env.xml
...
?
I do not have a src/main/webapp/WEB-INF directory, so what do I do?
You don't.
Dropwizard encapsulates most of the jetty configurations on its YAML configuration file. Reference
For others (context etc.) dropwizard has its own way of handling them programmatically. I highly suggest going through dropwizard's Getting started document as well as the user manual.

How to access classes in war from Wildfly module

I have a ear deployment which contain several war. A common library is needed by these wars so a custom module is created. This library would somehow load the classes in the war (using class.forName() may be)).
However, it seems that the module is not able to get access to the classes in the war and keep throwing ClassNotFoundException upon deployment.
Is there any configuration needed to expose the classes to be accessed by the module? I tried with those export=true settings on the module but get no luck with it.
The library I needed is DWR with spring FYI.

WAR outside the EAR, not able to reference JAR inside EAR. In wildfly 8

I am migrating to Wildfly 8.2 from JBoss 5.1, I am deploying a Web Service using the resteasy and some EAR which has the code to get the requested data from the DB. Both the EAR which has multiple (6) JARs, but when I call the Web Service, it is not able to find the EAR and refer it's JARs
14:57:48,183 INFO [stdout] (default task-4) InitialContextFactory not defined - using default: org.jnp.interfaces.NamingContextFactory
14:57:48,184 ERROR [stderr] (default task-4) javax.naming.NameNotFoundException: bpc/AccountManagementService -- service jboss.naming.context.java.bpc.AccountManagementService
I have 2 separate deployment of EAR and WAR and both of them are deployed simultaneously and they both get deployed without any hassle.
Why are then not able to integrate is my issue right now.
If you migrated from jboss 5 to wildfly, you have to adjust your jndi lookups.. You are getting a NameNotFoundException, so probably you are performing a lookup using the old jndi syntax..
When you startup your server, the log will show you different jndi names for your ejbs..
If you are looking for an ejb from a war, and both of them are not bundled in the same ear, then you have to use the java:global naming type..
For example, assuming that AccountManagementService is an interface, annotate it with #Remote, and search it from your war using the following jndi syntax
java:global/earName/ejb-jar-name/AccountManagementService!com.example.AccountManagementServiceImpl
See if this document helps (Modify JNDI lookup code section) https://docs.jboss.org/author/display/AS71/Order+Application+Migration+from+EAP5.1+to+AS7
I resolved this issue by adding jboss-deployment-structure.xml in my WAR file under the web-inf folder
by adding dependency like
dependencies>
<module name="deployment.MY_EAR.ear.MY_EJB_JAR.jar"/>
</dependencies>
I have similar issue.
I am migrating from weblogic to wildfly.
One JAR which has only one property file and one EAR, both are deployed simultaneously without any issue.
From EAR application, need to access the property file from the JAR.
This is working fine in weblogic but wildfly not identifying the property file.

Jetty and/or Servlet-api in JavaFX breaks deployment

I try to embed (use) Jetty into my JavaFX 2.2 applet (which runs in a browser).
My problem is that, to host servlets I need to include the servlet-api-3.0.jar also (for javax.servlet namespaces) besides jetty-server.jar, jetty-servlet.jar and jetty-util.jar.
If I include the servlet-api.jar, my project compiles, but when I run it inside the browser, the deployment fails with the "JavaFX application could not launch due to system configuration (show error details). See java.com/javafx for troubleshooting information." error message.
If I remove the servlet-api.jar (and remove the relevant source) it deploys again.
For the JavaFX project the Java Platform is set to "Default JavaFX Platform", and it would be good to keep it this way to reduce the minimum footprint required.
I'm not a java(fx) expert (I come from .NET world), so I'd appreciate any help!
You have an issue with signing the JARs. I'm not very familiar with signing JARs for JavaFX but here is the documentation:
http://docs.oracle.com/javafx/2/deployment/packaging.htm#BABJGFBH
http://docs.oracle.com/javafx/2/deployment/javafx_ant_task_reference001.htm#CIAFJGAB
servlet-api-3.0.jar is what's known as a provided dependency.
It is not needed to be included in your war file, as the web app container (in this case Jetty) provides it for you. In your build tool, just exclude the servlet-api.jar from being bundled in your war file.
Note: jetty-server-9.0.0.M5.jar is also a provided dependency and has the same rules.