I have installed cave-repository to Fuse and afterwards I created a new repository. When I try to reach repository via http, I receive the following error from undertow.
NOTE: I did no change to undertow settings. It is a default fuse package.
java.lang.IllegalStateException: UT010026: Async is not supported for
this request, as not all filters or Servlets were marked as supporting
async at
io.undertow.servlet.spec.HttpServletRequestImpl.startAsync(HttpServletRequestImpl.java:1023)
at
org.apache.karaf.cave.repository.service.maven.MavenServlet.doGet(MavenServlet.java:285)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:645) at
javax.servlet.http.HttpServlet.service(HttpServlet.java:750) at
io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
at
io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
at
io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
at
io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at
org.ops4j.pax.web.service.undertow.internal.Context$1.lambda$wrap$0(Context.java:615)
at
io.undertow.servlet.handlers.RedirectDirHandler.handleRequest(RedirectDirHandler.java:68)
at
io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
at
io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at
io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at
io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
at
io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
at
io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
io.undertow.servlet.handlers.SessionRestoringHandler.handleRequest(SessionRestoringHandler.java:119)
at
io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:269)
at
io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:78)
at
io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:133)
at
io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:130)
at
io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
at
io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at
io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249)
at
io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:78)
at
io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:99)
at
io.undertow.server.Connectors.executeRootHandler(Connectors.java:376)
at
io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
I tried the same steps (installing and creating cave repository) in karaf with jetty, and everything works fine there.
During the search in google, I have found the following page in redhat but due to subscription I am not able to see the content.
https://access.redhat.com/solutions/4222431
The problem is that (as I commented under https://ops4j1.jira.com/browse/PAXWEB-1254) Cave's MavenServlet is registered using plain HttpService.registerServlet() without specifying async supported flag. It works with Jetty only by coincidence (doesn't work - as expected - with pax-web-tomcat and pax-web-undertow).
Karaf Cave should either use Pax Web specific WebContainer extension to org.osgi.service.http.HttpService or register the servlet using annotations.
We'll continue the discussion in Karaf/Cave project.
Related
As the title says. I have some EJBs in an EAR and I have a client jar providing remote methods to a JSF app also sitting in liberty (different server/machine). The client jar tries to access the remote EJBs via lookup.
This is breaking my heart for two days now. As the title says...
I am aware of other stackoverflow questions from the past and I am aware of the following resources:
https://www.ibm.com/docs/en/was-liberty/core?topic=liberty-using-enterprise-javabeans-remote-interfaces
https://github.com/OpenLiberty/open-liberty/blob/release/dev/com.ibm.ws.ejbcontainer.remote_fat/test-applications/RemoteClientWeb.war/src/com/ibm/ws/ejbcontainer/remote/client/web/RemoteTxAttrServlet.java
I have tried every combination provided in the above but no joy.
I use (wlp-javaee8.21.0.0.8) with javaee8 feature enabled, this enables everything else I need e.g. ejb-3.2, ejbRemote-3.2, jndi-1.0 and a few others)
I have an EAR my-ear that contains a module my-module-1.0.4-SNAPSHOT.jar which contains my beans. I am using gradle/liberty plugin and IntelliJ.
I am using tests from within IntelliJ in the client jar module to try to access the remote beans.
My myEAR deploys fine and starts up fine and the app shows running in admincenter. In messages.log I see my EJB bindings. Just picking one example.
[16/08/21 10:58:42:384 IST] 00000022
com.ibm.ws.ejbcontainer.osgi.internal.NameSpaceBinderImpl I
CNTR0167I: The server is binding the
my.org.functiona.ejb.advance.MyAdvance interface of the MyAdvanceBean
enterprise bean in the my-module-1.0.4-SNAPSHOT.jar module of the
my-ear application. The binding location is:
ejb/my-ear/my-module-1.0.4-SNAPSHOT.jar/MyAdvanceBean#my.org.functiona.ejb.advance.MyAdvance
[16/08/21 10:58:42:385 IST] 00000022
com.ibm.ws.ejbcontainer.osgi.internal.NameSpaceBinderImpl I
CNTR0167I: The server is binding the
my.org.functiona.ejb.advance.MyAdvance interface of the MyAdvanceBean
enterprise bean in the my-module-1.0.4-SNAPSHOT.jar module of the
my-ear application. The binding location is:
my.org.functiona.ejb.advance.MyAdvance [16/08/21 10:58:42:385 IST]
00000022 com.ibm.ws.ejbcontainer.runtime.AbstractEJBRuntime
I CNTR0167I: The server is binding the
my.org.functiona.ejb.advance.MyAdvance interface of the MyAdvanceBean
enterprise bean in the my-module-1.0.4-SNAPSHOT.jar module of the
my-ear application. The binding location is:
java:global/my-ws-ear/my-module-1.0.4-SNAPSHOT.jar/MyAdvanceBean!my.org.functiona.ejb.advance.MyAdvance
This is my corresponding interface:
package my.org.functiona.ejb.advance;
import javax.ejb.Remote;
#Remote
public interface MyAdvance {
This is my corresponding implementation:
package my.org.functiona.ejb.advance;
import javax.ejb.EJB;
import javax.ejb.Stateless;
import javax.ejb.TransactionAttribute;
#Stateless(mappedName = "MyAdvance")
#TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
public class MyAdvanceBean implements MyAdvance {
Like I said, its breaking my heart. I tried every combination of provided in the (patchy) documentation and other sources. The most progress I made was by accessing "corbaname::localhost:2809/NameService" through a default InitialContext().lookup. So at least I was able to confirm I can gwet through to the NameService. But any subsequent bean lookup using that context with any combination of the names provided in messages.log or in the code snippets from documentation all fail with the exception below.
javax.naming.NameNotFoundException [Root exception is org.omg.CosNaming.NamingContextPackage.NotFound: IDL:omg.org/CosNaming/NamingContext/NotFound:1.0]
Same for InitialContext() lookups where I prefix the names with "corbaname::localhost:2809/NameService#".
I tried
ejb/my-ear/my-module-1.0.4-SNAPSHOT.jar/MyAdvanceBean#my.org.functiona.ejb.advance.MyAdvance
ejb/global/my-ear/my-module-1.0.4-SNAPSHOT.jar/MyAdvanceBean#my.org.functiona.ejb.advance.MyAdvance
ejb/my-ear/my-module-1.0.4-SNAPSHOT.jar/MyAdvance#my.org.functiona.ejb.advance.MyAdvance
ejb/global/my-ear/my-module-1.0.4-SNAPSHOT.jar/MyAdvance#my.org.functiona.ejb.advance.MyAdvance
java:global/my-ear/my-module-1.0.4-SNAPSHOT.jar/MyAdvance#my.org.functiona.ejb.advance.MyAdvance
java:global/my-ear/my-module-1.0.4-SNAPSHOT.jar/MyAdvanceBean#my.org.functiona.ejb.advance.MyAdvance
my.org.functiona.ejb.advance.MyAdvance
and probably a few others
I replaced the # sign with an exclamation mark in all of the above. And went through it again.
I tried corbaloc:: and corbaloc:iiop: for context. Nothing.
I am no web dev expert but this feels very try and error and I dont feel it should be like that. I understand in websphere proper I could identify the names in the admin console but then I'm not even certain websphere proper and liberty behave the same way.
Sine accessing EJBs from remote seems bread & butter stuff I assume I am overlooking something basic and silly due to my inexperience.
Any pointers anyone? Thank you so much for your time reading this.
Carsten
Edit: server.xml
<server description="disbCoreServer">
<featureManager>
<feature>javaee-8.0</feature>
<feature>adminCenter-1.0</feature>
<feature>websocket-1.1</feature>
</featureManager>
<quickStartSecurity userName="admin" userPassword="carsten" />
<!-- To access this server from a remote client add a host attribute to the following element, e.g. host="*" -->
<httpEndpoint id="defaultHttpEndpoint"
host="${hostname}"
httpPort="${default.http.port}"
httpsPort="${default.https.port}">
<accessLogging filepath="${com.ibm.ws.logging.log.directory}/accessLog.log" logFormat='%h %i %u %t "%r" %s %b %{R}W' />
<tcpOptions soReuseAddr="true" />
</httpEndpoint>
<include location="appConfXML/disb_core_jndi.xml"/>
<include location="appConfXML/disb_core_jdbc.xml"/>
<include location="appConfXML/disb_core_jms.xml"/>
<include location="appConfXML/disb_core_mail.xml"/>
</server>
The example provided through the FAT test (remoteLookup) works just fine. I just didnt have all my ducks in a row.
https://github.com/OpenLiberty/open-liberty/blob/release/dev/com.ibm.ws.ejbcontainer.remote_fat/test-applications/RemoteClientWeb.war/src/com/ibm/ws/ejbcontainer/remote/client/web/RemoteTxAttrServlet.java
My scenario is serverA hosting EJBs and serverB running the remote client calling serverA's EJBs.
Steps on serverB are:
Get (local) InitialContext with no properties: InitialContext initialContext = new InitialContext();
With the above lookup the remote Context: Context remoteContext = (Context) initialContext.lookup("corbaname::remotehost:remotePort/NameService");
With the remoteContext lookup the EJB remote interfaces and 'narrow' and cast them to appropriate type
String lookupName = "ejb/global" + "/" + "MyAppName" + "/" + "MyModuleName" + "/" + jndiName;
Object remoteObj = remoteContext.lookup(lookupName);
return interfaceClass.cast(PortableRemoteObject.narrow(remoteObj, interfaceClass));
Where
"MyAppName" is my apps name, the name of the EAR in my case (without .jar)
"MyModuleName" is the name of the EJB module within my EAR (without .jar)
and jndiName is the bean name / fully qualified interface name separated by exclamation mark e.g. "MyBean!myorg.ejb.interfaces.MyBeanIfc"
Call the interfaces to remotely execute serverA EJB code
Note: When running serverA and serverB on the same machine (e.g. localhost) ensure they are not operating on the same port for NameService.
Thanks to everyone who tried to help!
This code
private AlternatorDBClientV2 Client;
#Before
public void setUp() throws Exception {
this.Client = new AlternatorDBClientV2();
}
gives me this exception
java.lang.IllegalStateException: Unrecognized prefix for the AWS http client class name AlternatorDBClientV2
at com.amazonaws.AmazonWebServiceClient.computeServiceName(AmazonWebServiceClient.java:546)
at com.amazonaws.AmazonWebServiceClient.getServiceNameIntern(AmazonWebServiceClient.java:509)
at com.amazonaws.AmazonWebServiceClient.configSigner(AmazonWebServiceClient.java:202)
at com.amazonaws.AmazonWebServiceClient.setEndpoint(AmazonWebServiceClient.java:135)
at com.michelboudreau.alternatorv2.AlternatorDBClientV2.setEndpoint(AlternatorDBClientV2.java:273)
at com.michelboudreau.alternatorv2.AlternatorDBClientV2.init(AlternatorDBClientV2.java:109)
at com.michelboudreau.alternatorv2.AlternatorDBClientV2.<init>(AlternatorDBClientV2.java:96)
at com.michelboudreau.alternatorv2.AlternatorDBClientV2.<init>(AlternatorDBClientV2.java:91)
at com.salesfront.test.CreateUserTest.setUp(CreateUserTest.java:51)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
The stack trace line numbers indicate you have configured version 1.6.8 of the AWS Java SDK on your application's pom.xml file.
I reviewed successive Git tags for the AWS Java SDK project which I cloned to my workstation from its GitHub site:
https://github.com/aws/aws-sdk-java
The Alternator project is built and regression tested using version 1.6.4 of the AWS Java SDK.
Since version 1.6.4 of the AWS Java SDK Amazon has been adding logic to auto-detect the data center region and service to connect to based on parsing the endpoint URL and the actual name of the specific sub-class of AmazonWebServiceClient.java
The Alternator emulator clients are just such sub-classes of AmazonWebServiceClient but they do not follow the expected naming conventions.
To use the current version of Alternator you should revise your pom.xml to reference version 1.6.4 of the AWS Java SDK. You can experiment with using version 1.6.5, 1.6.6, or 1.6.7, but definitely 1.6.8 is incompatible with Alternator.
There is a pending Pull Request at the Alternator GitHub repository that resolves this issue.
https://github.com/mboudreau/Alternator/pull/84
Since the original answer, newer versions of Alternator have been created that allow use of higher versions 1.6 and 1.7 of the AWS SDK for Java.
Refer to the Issues and Pull Requests sections of the Alternator GitHub repository:
https://github.com/mboudreau/Alternator
java.lang.IllegalStateException: STREAM
at org.mortbay.jetty.Response.getWriter(Response.java:616)
at org.apache.jasper.runtime.JspWriterImpl.initOut(JspWriterImpl.java:187)
at org.apache.jasper.runtime.JspWriterImpl.flushBuffer(JspWriterImpl.java:180)
at org.apache.jasper.runtime.PageContextImpl.release(PageContextImpl.java:237)
at org.apache.jasper.runtime.JspFactoryImpl.internalReleasePageContext(JspFactoryImpl.java:173)
at org.apache.jasper.runtime.JspFactoryImpl.releasePageContext(JspFactoryImpl.java:124)
at org.apache.jsp.admin.index_jsp._jspService(org.apache.jsp.admin.index_jsp:415)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:109)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:389)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:486)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:380)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:401)
at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450)
at org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:327)
at org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:126)
at org.mortbay.jetty.servlet.DefaultServlet.doGet(DefaultServlet.java:503)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1221)
at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:306)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:399)
at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450)
at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:928)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228)
at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
2013-04-03 09:45:39.844:WARN::/solr/admin/
The above is the stacktrace that i get when try to check if solr is running by going to the admin page. I have solr integration module 7.x.1.x-dev for drupal 7 and i am using its schema.xml and solrconfig.xml on Apache Solr 3.2. In the browser, when i request the page it says missing core name in path. What would be wrong ?
Usually try to change the solrconfig.xml or schema.xml in your example/solr/conf dir or it may be related to your version of Java. One of the two most likely.
I am testing JBoss AS 7 prior to deployment with a .war file of an app running in a different server.
I get this error when I try to log onto the database via the app:
SEVERE [] (http--0.0.0.0-8080-4) java.lang.NoClassDefFoundError: org/apache/commons/codec/DecoderException
java.lang.ClassNotFoundException: org.apache.commons.codec.DecoderException from [Module "deployment.app.war:main" from Service Module Loader]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)
at org.apache.commons.httpclient.HttpMethodBase.<init>(HttpMethodBase.java:220)
In some forums, they suggest adding the commons-codec jar, but I already have it in JBoss, right? (in here: jboss-as-7.1.1.Final/modules/org/apache/commons/codec/main/commons-codec-1.4.jar)
OSGi is not activated, frankly I have no idea to what purpose it serves, but when I try to activate it it messes with my war as it fails to deploy...
I have JDK, but no JRE if that's any help.
JBoss AS 7 does not use OSGi by default for modular class loading. It uses JBoss Modules so this has nothing to do with OSGi.
What you need to do if you want to use the commons-codec provided with JBoss AS 7 is add a dependency to your deployment.
Modules are not visible by your artefact classes automatically. You have three possibilities:
Define a global module in your standalone.xml
http://javahowto.blogspot.de/2012/09/how-to-create-global-modules-in-jboss.html
This module will be used by all artefacts you are deploying on Jboss.
Put it into your war artefact, into the lib folder. You can do that with Maven.
Define an explicit dependency within your Manifest. https://docs.jboss.org/author/display/AS7/Class+Loading+in+AS7
Section Dependencies: Manifest Entries
I paste one jar in repository/components/lib/ as dependence, but the wso2app does not find it when accessing the service, it throws the exception:
java.lang.ClassNotFoundException: Class Not found : br.org.test.MyClassTest
How can I fix this? Where should I put the jars for dependencies?
Try putting the jar file in $CARBON_HOME/repository/components/extensions directory and do not forget to restart the server after adding the library.
Source: How to Add External Jar Libraries to WSO2 Carbon based Products.
After a long research i finally was able to solve this by putting my dependencies in /lib/runtimes/ext.
Following this documentation. https://docs.wso2.com/display/AS530/Configuring+Runtime+Environment