[JBoss JIRA] (JGRP-2112) Sticky site masters
by Sebastian Łaskawiec (JIRA)
[ https://issues.jboss.org/browse/JGRP-2112?page=com.atlassian.jira.plugin.... ]
Sebastian Łaskawiec updated JGRP-2112:
--------------------------------------
Comment: was deleted
(was: This probably can't happen if the sites use Load Balancers as frontends. This way you will never send a message from C (LON) to C1 and C2 (NYC).)
> Sticky site masters
> -------------------
>
> Key: JGRP-2112
> URL: https://issues.jboss.org/browse/JGRP-2112
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.12, 4.0
>
>
> If members in one site send messages to site masters of other sites, if we have multiple site masters, then reordering can occur.
> Example:
> * Member C in site LON sends messages C1 and C2 to site NYC
> * C1 picks SM1 and C2 picks SM2
> * Although site masters process messages in delivery order, because C1 and C2 travel through different site masters, C2 could pass C1, leading to ordering issues
> h4. Design
> * When sending a message to the one of the site masters of the current site, or from a site master to a remote site master, we invoke a callback to pick the site master based on the original caller
> * Note that this only applies when we have more than one site master.
> * The callback passes the address of the original caller and the list of available site masters, and needs to return a site master
> h5. Transactions
> * Transactions by different originators with overlapping key sets cannot be reliably ordered
> * Transactional support therefore requires single site masters
> * This should not be an issue as transactions bundle multiple updates, so the number of messages sent is less than non-transactional updates
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (JGRP-2253) FD_SOCK is not working in AWS environment
by Sibin Karnavar (JIRA)
[ https://issues.jboss.org/browse/JGRP-2253?page=com.atlassian.jira.plugin.... ]
Sibin Karnavar updated JGRP-2253:
---------------------------------
Description:
We have our failure detection defined like below.
<FD_SOCK external_port="7804" />
<FD timeout="3000" max_tries="3" />
<VERIFY_SUSPECT timeout="3000" />
Please note that we have used FD instead of FD_ALL in AWS. We will be changing it to FD_ALL later after detailed testing.
In my local, this is working perfect. As soon as I kill my node, I was able to see that view change was happening immediately with FD_SOCK.
We were not mentioning the external_port in the FD_SOCK but later I thought it may be an issue with the port and defined it as 7804 and added the same port to the security group that allows to access this port among all the nodes. So no issue with the port.
Can you please let us know if we need any additional configurations to make FD_SOCK works well in AWS.
Thanks,
Sibin
was:
We have our failure detection defined like below.
<FD_SOCK external_port="7804" />
<FD timeout="3000" max_tries="3" />
<VERIFY_SUSPECT timeout="3000" />
Please note that we have used FD instead of FD_ALL in AWS. We will be changing it to FD_ALL later after detailed testing.
In my local, this is working perfect. as soon as I kill my node, i was able to see that view change was happening immediately with FD_SOCK.
We were not mentioning the external_port in the FD_SOCK but later I thought it may be issue with the port and defined it as 7804 and added the same port to the security group that allows to access this port among all the nodes. So no issue with the port.
Can you please let us know if we need any additional configurations to make FD_SOCK works well in AWS.
Thanks,
Sibin
> FD_SOCK is not working in AWS environment
> -----------------------------------------
>
> Key: JGRP-2253
> URL: https://issues.jboss.org/browse/JGRP-2253
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.10
> Environment: AWS - EC2
> Reporter: Sibin Karnavar
> Assignee: Bela Ban
>
> We have our failure detection defined like below.
> <FD_SOCK external_port="7804" />
> <FD timeout="3000" max_tries="3" />
> <VERIFY_SUSPECT timeout="3000" />
> Please note that we have used FD instead of FD_ALL in AWS. We will be changing it to FD_ALL later after detailed testing.
> In my local, this is working perfect. As soon as I kill my node, I was able to see that view change was happening immediately with FD_SOCK.
> We were not mentioning the external_port in the FD_SOCK but later I thought it may be an issue with the port and defined it as 7804 and added the same port to the security group that allows to access this port among all the nodes. So no issue with the port.
> Can you please let us know if we need any additional configurations to make FD_SOCK works well in AWS.
> Thanks,
> Sibin
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (JGRP-2253) FD_SOCK is not working in AWS environment
by Sibin Karnavar (JIRA)
[ https://issues.jboss.org/browse/JGRP-2253?page=com.atlassian.jira.plugin.... ]
Sibin Karnavar commented on JGRP-2253:
--------------------------------------
And I was able to see that this thread was running in each of the nodes in AWS environment -> 'FD_SOCK acceptor-10.......'
> FD_SOCK is not working in AWS environment
> -----------------------------------------
>
> Key: JGRP-2253
> URL: https://issues.jboss.org/browse/JGRP-2253
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.10
> Environment: AWS - EC2
> Reporter: Sibin Karnavar
> Assignee: Bela Ban
>
> We have our failure detection defined like below.
> <FD_SOCK external_port="7804" />
> <FD timeout="3000" max_tries="3" />
> <VERIFY_SUSPECT timeout="3000" />
> Please note that we have used FD instead of FD_ALL in AWS. We will be changing it to FD_ALL later after detailed testing.
> In my local, this is working perfect. as soon as I kill my node, i was able to see that view change was happening immediately with FD_SOCK.
> We were not mentioning the external_port in the FD_SOCK but later I thought it may be issue with the port and defined it as 7804 and added the same port to the security group that allows to access this port among all the nodes. So no issue with the port.
> Can you please let us know if we need any additional configurations to make FD_SOCK works well in AWS.
> Thanks,
> Sibin
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (JGRP-2253) FD_SOCK is not working in AWS environment
by Sibin Karnavar (JIRA)
Sibin Karnavar created JGRP-2253:
------------------------------------
Summary: FD_SOCK is not working in AWS environment
Key: JGRP-2253
URL: https://issues.jboss.org/browse/JGRP-2253
Project: JGroups
Issue Type: Bug
Affects Versions: 4.0.10
Environment: AWS - EC2
Reporter: Sibin Karnavar
Assignee: Bela Ban
We have our failure detection defined like below.
<FD_SOCK external_port="7804" />
<FD timeout="3000" max_tries="3" />
<VERIFY_SUSPECT timeout="3000" />
Please note that we have used FD instead of FD_ALL in AWS. We will be changing it to FD_ALL later after detailed testing.
In my local, this is working perfect. as soon as I kill my node, i was able to see that view change was happening immediately with FD_SOCK.
We were not mentioning the external_port in the FD_SOCK but later I thought it may be issue with the port and defined it as 7804 and added the same port to the security group that allows to access this port among all the nodes. So no issue with the port.
Can you please let us know if we need any additional configurations to make FD_SOCK works well in AWS.
Thanks,
Sibin
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (WFLY-9884) WeldResourceInjectionServices runs into NoSuchElementException when deploying multiple EJBs
by Jacob Ilsø (JIRA)
[ https://issues.jboss.org/browse/WFLY-9884?page=com.atlassian.jira.plugin.... ]
Jacob Ilsø commented on WFLY-9884:
----------------------------------
[~jaikiran] With the first version of your PR I can no longer reproduce the issue. I will try reproducing again when the PR is final. Thanks.
> WeldResourceInjectionServices runs into NoSuchElementException when deploying multiple EJBs
> -------------------------------------------------------------------------------------------
>
> Key: WFLY-9884
> URL: https://issues.jboss.org/browse/WFLY-9884
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 11.0.0.Final, 12.0.0.Beta1
> Environment: Windows 8.1 Enterprise.
> Reporter: Jacob Ilsø
> Assignee: Jason Greene
> Attachments: log.txt
>
>
> I have an EAR file with several "@Singleton @Startup" beans. Each bean having a number of @Inject and @Resource fields. When I deploy the EAR in WildFly 11 it sometimes fails with a NoSuchElementException (see [^log.txt] for a full stacktrace).
> I cannot reproduce it consistently but it seems to only happen on a "clean" WildFly installation. I haven't seen this on earlier versions of WildFly.
> Let me know if you want me to try to build an EAR for reproducing this.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (WFLY-9869) Pure HTTP EJB invocation not working
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/WFLY-9869?page=com.atlassian.jira.plugin.... ]
jaikiran pai edited comment on WFLY-9869 at 2/22/18 9:34 AM:
-------------------------------------------------------------
FWIW - A quick look suggests that the HTTP {{EJBTransportProvider}} isn't (auto) registered for deployments, thus causing EJB invocations from servers (which act as a client in the invocation), failing for the {{http}} scheme.
Edit: I didn't notice that Stuart already sent a PR to fix this.
was (Author: jaikiran):
FWIW - A quick look suggests that the HTTP {{EJBTransportProvider}} isn't (auto) registered for deployments, thus causing EJB invocations from servers (which act as a client in the invocation), failing for the {{http}} scheme.
> Pure HTTP EJB invocation not working
> ------------------------------------
>
> Key: WFLY-9869
> URL: https://issues.jboss.org/browse/WFLY-9869
> Project: WildFly
> Issue Type: Quality Risk
> Components: EJB
> Affects Versions: 11.0.0.Final, 12.0.0.Beta1
> Environment: Debian 9 - 64-bit
> Reporter: Andre Izu
> Assignee: Stuart Douglas
> Labels: ejb, pure_http
> Attachments: ejb-http-client.zip
>
>
> I have been trying to make the "pure" http EJB invocation from a remote server instance, without success.
> The client module was built inside a war file, while the server artifact was build in an ear file.
> When I set the Context.PROVIDER_URL to "remote+http://127.0.0.1:8080" or "http://localhost:8080/wildfly-services", the remote invocation works fine via main() method.
> When I set the Context.PROVIDER_URL to "remote+http://127.0.0.1:8080", the remote invocation works fine via http://localhost:8080/web/index.jsp (client application calling server application)
> Now when I set the Context.PROVIDER_URL to "http://localhost:8080/wildfly-services", the remote invocation via http://localhost:8080/web/index.jsp (client application calling server application) returns:
> {panel:title=Client application calling server application}
> 2018-01-05 15:30:07,346 INFO [stdout] (default task-44) jndiName: ejb:wejb/wejb/CalculatorEJB!br.com.server.Calculator
> 2018-01-05 15:30:07,351 INFO [stdout] (default task-44) Proxy for remote EJB StatelessEJBLocator for "wejb/wejb/CalculatorEJB", view is interface br.com.server.Calculator, affinity is None
> 2018-01-05 15:30:07,352 ERROR [io.undertow.request] (default task-44) UT005023: Exception handling request to /web/: org.apache.jasper.JasperException: org.jboss.ejb.client.RequestSendFailedException: EJBCLIENT000409: No more destinations are available
> at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:473)
> at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:403)
> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:347)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.jsp.JspFileHandler.handleRequest(JspFileHandler.java:32)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> 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.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction$$Lambda$852/801580157.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$853/1002843216.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$853/1002843216.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$853/1002843216.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$853/1002843216.call(Unknown Source)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:326)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.jboss.ejb.client.RequestSendFailedException: EJBCLIENT000409: No more destinations are available
> at org.jboss.ejb.client.EJBReceiverInvocationContext$ResultProducer$Failed.getResult(EJBReceiverInvocationContext.java:151)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:567)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:503)
> at org.jboss.ejb.protocol.remote.RemotingEJBClientInterceptor.handleInvocationResult(RemotingEJBClientInterceptor.java:56)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:569)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:503)
> at org.jboss.ejb.client.TransactionPostDiscoveryInterceptor.handleInvocationResult(TransactionPostDiscoveryInterceptor.java:133)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:569)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:503)
> at org.jboss.ejb.client.DiscoveryEJBClientInterceptor.handleInvocationResult(DiscoveryEJBClientInterceptor.java:118)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:569)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:503)
> at org.jboss.ejb.client.NamingEJBClientInterceptor.handleInvocationResult(NamingEJBClientInterceptor.java:78)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:569)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:503)
> at org.jboss.ejb.client.TransactionInterceptor.handleInvocationResult(TransactionInterceptor.java:172)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:569)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:503)
> at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:907)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:165)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:100)
> at com.sun.proxy.$Proxy61.calculateInterest(Unknown Source)
> at br.com.client.RemoteEJBClient.main(RemoteEJBClient.java:20)
> at br.com.client.RemoteEJBClient.func(RemoteEJBClient.java:14)
> at org.apache.jsp.index_jsp._jspService(index_jsp.java:99)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:433)
> ... 47 more
> Suppressed: javax.ejb.NoSuchEJBException: EJBCLIENT000024: No EJB receiver available for handling destination "http://localhost:8080/wildfly-services"
> at org.jboss.ejb.client.EJBClientContext.resolveReceiver(EJBClientContext.java:571)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:438)
> at org.jboss.ejb.protocol.remote.RemotingEJBClientInterceptor.handleInvocation(RemotingEJBClientInterceptor.java:51)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:466)
> at org.jboss.ejb.client.TransactionPostDiscoveryInterceptor.handleInvocation(TransactionPostDiscoveryInterceptor.java:79)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:466)
> at org.jboss.ejb.client.DiscoveryEJBClientInterceptor.handleInvocation(DiscoveryEJBClientInterceptor.java:90)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:466)
> at org.jboss.ejb.client.NamingEJBClientInterceptor.handleInvocation(NamingEJBClientInterceptor.java:66)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:466)
> at org.jboss.ejb.client.TransactionInterceptor.handleInvocation(TransactionInterceptor.java:165)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:466)
> at org.jboss.ejb.client.EJBClientInvocationContext$$Lambda$915/72354668.accept(Unknown Source)
> at org.wildfly.common.context.Contextual.runExConsumer(Contextual.java:203)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequestInitial(EJBClientInvocationContext.java:302)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:161)
> ... 55 more
> {panel}
> This behaviour is reproduceable with the attached project. One detail not mentioned in the jboss forum is that I started wildfly 11 with standalone-full.xml
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (WFLY-9881) UnsatisfiedLinkError - Open CV
by Jive JIRA Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-9881?page=com.atlassian.jira.plugin.... ]
Jive JIRA Integration updated WFLY-9881:
----------------------------------------
Forum Reference: https://developer.jboss.org/message/980386#980386
> UnsatisfiedLinkError - Open CV
> --------------------------------
>
> Key: WFLY-9881
> URL: https://issues.jboss.org/browse/WFLY-9881
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 11.0.0.Final
> Environment: Windows Server 2012 R2 \ Windows 8.1 Professional, 64 bit JRE\JDK 8 update 112
> OpenCV 3.3.0 (https://github.com/opencv/opencv/releases/tag/3.3.0)
> Reporter: Richard Cannock
> Assignee: Jason Greene
>
> Deploying a simple Stateless session bean with a single get method that has a dependency on OpenCV release 3.3.0 (opencv-330.jar) and it's corresponding 64 bit native library (opencv_java330.dll) from https://github.com/opencv/opencv/releases/tag/3.3.0
> results in a UnsatisfiedLinkError:
> Caused by: java.lang.UnsatisfiedLinkError: org.opencv.core.Mat.n_eye(III)J
> at org.opencv.core.Mat.n_eye(Native Method)
> at org.opencv.core.Mat.eye(Mat.java:492)
> at test.SimpleJMSRestfulWebService.putMessage(SimpleJMSRestfulWebService.java:57)
> The sample get method is shown below:
> package test;
> import javax.ejb.Stateless;
> import javax.ws.rs.GET;
> import javax.ws.rs.Path;
> import org.opencv.core.Core;
> import org.opencv.core.CvType;
> import org.opencv.core.Mat;
> /**
> *
> */
> @Stateless
> @Path("/jms")
> public class SimpleJMSRestfulWebService
> {
> /**
> * Our RESTful webservice
> */
> @GET
> public String putMessage()
> {
> System.loadLibrary(Core.NATIVE_LIBRARY_NAME);
> Mat mat = Mat.eye(3, 3, CvType.CV_8UC1);
> System.out.println("mat = " + mat.dump());
> return "works";
> }
> }
> The native library is placed in C:\Windows, which is in the java.library.path system variable.
> Same code runs without exception in GlassFish Server 4.1 and also within netbeans 8.2 (albeit in a differnet test harness)
> Using -Djava.library.path VM argumnents using a different path for the native library also causes the same error.in wildfly.
> Removing the library from C:\Windows causes a different stack trace, which suggests that wildfly is at least partially loading the library:
> Caused by: java.lang.UnsatisfiedLinkError: no opencv_java330 in java.library.path
> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1867)
> at java.lang.Runtime.loadLibrary0(Runtime.java:870)
> at java.lang.System.loadLibrary(System.java:1122)
> Using depends.exe or dependency walker on opencv_java330.dll reports no unsatisfied dependencies for this dll.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months