[JBoss JIRA] (WFLY-9801) Wsprovide tool ends with java.security.AccessControlException
by Rostislav Svoboda (JIRA)
[ https://issues.jboss.org/browse/WFLY-9801?page=com.atlassian.jira.plugin.... ]
Rostislav Svoboda reopened WFLY-9801:
-------------------------------------
Hi Rebecca.
I'm reopening this as proposed workaround is not suitable for end users.
when a command worked before, the same command must work now too.
No additional parameters or permission files are acceptable, backward compatibility must be preserved. Customers can be using such scripts in automated fashion too.
It seems to me that WFLY-9868 looks like workaround for this. Am I right ?
Even if WFLY-9868 is the workaround for this problem, I believe this issue should be still kept open. CXF should be fixed so the compiler is located using ServiceLoader as David suggests.
[~asoldano] wdyt ?
> Wsprovide tool ends with java.security.AccessControlException
> -------------------------------------------------------------
>
> Key: WFLY-9801
> URL: https://issues.jboss.org/browse/WFLY-9801
> Project: WildFly
> Issue Type: Bug
> Components: Scripts, Web Services
> Reporter: Marek Kopecký
> Assignee: R Searls
> Priority: Critical
> Fix For: 12.0.0.CR1
>
> Attachments: Echo1-security.policy, Echo1.class, Echo1Impl.class
>
>
> *Description of the issue:*
> wsprovide tool ends with java.security.AccessControlException
> I see this issue on WF master (2018_02_12). This is regression against WF master from 2018_02_05, so priority of this jira is blocker.
> *How reproducible:*
> Always
> *Steps to Reproduce:*
> # Use these (class files are attached):
> {code:java}
> @WebService(endpointInterface = "org.jboss.as.testsuite.integration.scripts.test.tools.Echo1", targetNamespace = "org.jboss.as.testsuite.integration.scripts.test.tools", serviceName = "Echo1Service")
> public class Echo1Impl implements Echo1 {
> @Override
> public String echoPlus1(String s) {
> return s + "1";
> }
> }
> {code}
> {code:java}
> @WebService
> @SOAPBinding
> public interface Echo1 {
> String echoPlus1(String s);
> }
> {code}
> # cd $\{JBOSS_HOME\}/bin
> # mkdir out
> # ./wsprovide.sh -k -c $\{CLASS_DIR\} -o out org.jboss.as.testsuite.integration.scripts.test.tools.Echo1Impl
> *Actual results:*
> {noformat}
> [mkopecky@localhost bin]$ ./wsprovide.sh -k -c ~/erase2 -o out org.jboss.as.testsuite.integration.scripts.test.tools.Echo1Impl
> Could not find log4j.properties or log4j.xml configuration, logging to console.
> java2ws -s /home/mkopecky/playground/wf/wfly.13/wfly.13/bin/out -classdir /home/mkopecky/playground/wf/wfly.13/wfly.13/bin/out -d /home/mkopecky/playground/wf/wfly.13/wfly.13/bin/out -verbose -cp /home/mkopecky/erase2/: -wrapperbean -createxsdimports org.jboss.as.testsuite.integration.scripts.test.tools.Echo1Impl
> java2ws - Apache CXF 3.2.2
> java.security.AccessControlException: access denied ("java.io.FilePermission" "/home/mkopecky/playground/wf/wfly.13/wfly.13/bin/out/org/jboss/as/testsuite/integration/scripts/test/tools/jaxws/EchoPlus1Response.java" "read")
> at java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
> at java.security.AccessController.checkPermission(AccessController.java:884)
> at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
> at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
> at java.io.File.isDirectory(File.java:844)
> at com.sun.tools.javac.file.RegularFileObject.<init>(RegularFileObject.java:69)
> at com.sun.tools.javac.file.RegularFileObject.<init>(RegularFileObject.java:64)
> at com.sun.tools.javac.file.JavacFileManager.getJavaFileObjectsFromFiles(JavacFileManager.java:785)
> at com.sun.tools.javac.file.JavacFileManager.getJavaFileObjectsFromStrings(JavacFileManager.java:185)
> at org.apache.cxf.common.util.Compiler.useJava6Compiler(Compiler.java:202)
> at org.apache.cxf.common.util.Compiler.compileFiles(Compiler.java:141)
> at org.apache.cxf.tools.java2wsdl.generator.wsdl11.BeanGenerator.generateAndCompile(BeanGenerator.java:91)
> at org.apache.cxf.tools.java2wsdl.generator.wsdl11.BeanGenerator.generate(BeanGenerator.java:58)
> at org.apache.cxf.tools.java2wsdl.generator.wsdl11.BeanGenerator.generate(BeanGenerator.java:35)
> at org.apache.cxf.tools.java2wsdl.processor.JavaToWSDLProcessor.generate(JavaToWSDLProcessor.java:156)
> at org.apache.cxf.tools.java2wsdl.processor.JavaToWSDLProcessor.process(JavaToWSDLProcessor.java:118)
> at org.apache.cxf.tools.java2ws.JavaToWSContainer.processWSDL(JavaToWSContainer.java:110)
> at org.apache.cxf.tools.java2ws.JavaToWSContainer.execute(JavaToWSContainer.java:75)
> at org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:105)
> at org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:45)
> at org.apache.cxf.tools.java2ws.JavaToWS.run(JavaToWS.java:83)
> at org.jboss.wsf.stack.cxf.tools.CXFProviderImpl.provide(CXFProviderImpl.java:200)
> at org.jboss.wsf.stack.cxf.tools.CXFProviderImpl.provide(CXFProviderImpl.java:109)
> at org.jboss.ws.tools.cmd.WSProvide.generate(WSProvide.java:223)
> at org.jboss.ws.tools.cmd.WSProvide.main(WSProvide.java:89)
> at org.jboss.modules.Module.runMainMethod(Module.java:348)
> at org.jboss.modules.Module.run(Module.java:328)
> at org.jboss.modules.Main.main(Main.java:557)
> {noformat}
> *Expected results:*
> No errors
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (WFLY-9880) ServletContainerInitializer@onStartup is not invoked for deployment
by Jan Stourac (JIRA)
Jan Stourac created WFLY-9880:
---------------------------------
Summary: ServletContainerInitializer@onStartup is not invoked for deployment
Key: WFLY-9880
URL: https://issues.jboss.org/browse/WFLY-9880
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 12.0.0.Beta1
Reporter: Jan Stourac
Assignee: Stuart Douglas
Attachments: deployment-with-dep.war, module.xml, servlet-container-init.jar
The {{ServletContainerInitializer@onStartup}} is not invoked for deployment. See {{Steps to Reproduce}}.
Problematic part seems to be on [this line|https://github.com/undertow-io/undertow/blob/1706a5f41adb8f1a719617c...] in Undertow
{code}
//then run the SCI's
---> for (final ServletContainerInitializerInfo sci : deploymentInfo.getServletContainerInitializers()) {
final InstanceHandle<? extends ServletContainerInitializer> instance = sci.getInstanceFactory().createInstance();
try {
instance.getInstance().onStartup(sci.getHandlesTypes(), servletContext);
} finally {
instance.release();
}
}
{code}
It looks like calling {{deploymentInfo.getServletContainerInitializers()}} does not include our deployment and simply ignores it.
--
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 Andre Izu (JIRA)
[ https://issues.jboss.org/browse/WFLY-9869?page=com.atlassian.jira.plugin.... ]
Andre Izu updated WFLY-9869:
----------------------------
Description:
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
was:
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 details not mentioned in the jboss forum is that I started wildfly 11 with standalone-full.xml
> 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
> Environment: Debian 9 - 64-bit
> Reporter: Andre Izu
> 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-9878) EclipseLink Entity Scanning broken in Wildfly 11
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-9878?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-9878:
------------------------------------
Also, please list the contents of your ear and/or war/jar files. If you don't want to list the entire contents, that is fine, I'm just curious as to where the persistence.xml file is and where the entity classes are as well, in your deployment.
> EclipseLink Entity Scanning broken in Wildfly 11
> ------------------------------------------------
>
> Key: WFLY-9878
> URL: https://issues.jboss.org/browse/WFLY-9878
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 11.0.0.Final
> Environment: Enterprise Maven Project
> Wildfly 11
> Eclipse Link 2.7.1 (2.6.3 and 2.64 were also tested)
> Reporter: Alessandro Moscatelli
> Assignee: Scott Marlow
> Fix For: 12.0.0.Final
>
>
> Following :
> https://docs.jboss.org/author/display/WFLY/JPA+Reference+Guide#JPAReferen...
> When you try to persist ANY entity (located in ejb, or jar or anywhere you want) if such entity is not listed in persistence.xml you'll get a :
> Caused by: javax.ejb.EJBException: java.lang.IllegalArgumentException: Object: org.visiontech.optoplus.entity.Provider[ id=null ] is not a known Entity type
> If I list such entity in persistence.xml the error is gone and the entity is persisted.
> Inside standalone.xml I used :
> <system-properties>
> ...
> <property name="eclipselink.archive.factory" value="org.jipijapa.eclipselink.JBossArchiveFactoryImpl"/>
> </system-properties>
> Is this a problem related to the last version (11 Final) of jipijapa.eclipselink ?
> I found several topic stating that what I done worked with Wildfly 10 and older version of jipijapa.
> I tried several combination of older jipijapa and eclipselink versions without success.
> I have about 130 entities in my probject, I'd REALLY love not to enlist them all.
> My persistence.xml :
> <persistence-unit name="optoplus">
> <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
> <jta-data-source>java:/jdbc/db_optoplus</jta-data-source>
> <exclude-unlisted-classes>false</exclude-unlisted-classes>
> </persistence-unit>
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (ELY-1523) Update the JAPICMP settings so that we only detect changes that break API compatibility
by Farah Juma (JIRA)
Farah Juma created ELY-1523:
-------------------------------
Summary: Update the JAPICMP settings so that we only detect changes that break API compatibility
Key: ELY-1523
URL: https://issues.jboss.org/browse/ELY-1523
Project: WildFly Elytron
Issue Type: Task
Components: Build
Reporter: Farah Juma
Currently, the JAPICMP settings will result in a build failure if new public API has been added. As we will be tagging .Final releases more regularly, we need to be able to allow new public API into a patch release so we should only be detecting changes that break API compatibility not changes that add new public API.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (WFLY-9878) EclipseLink Entity Scanning broken in Wildfly 11
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-9878?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-9878:
------------------------------------
jboss.as.jpa.providerModule is the name of the persistence provider module (default is org.hibernate), you do not need to set that, as it will be derived from the provider=org.eclipse.persistence.jpa.PersistenceProvider.
I assume that some code change is likely needed, so to account for the difference between the simple unit test and your application. Most likely, something is going wrong in the org.jipijapa.eclipselink.JBossArchiveFactoryImpl class, would be my guess. I suppose that something in org.eclipse.persistence.internal.jpa.deployment.ArchiveFactoryImpl may also be going wrong.
> EclipseLink Entity Scanning broken in Wildfly 11
> ------------------------------------------------
>
> Key: WFLY-9878
> URL: https://issues.jboss.org/browse/WFLY-9878
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 11.0.0.Final
> Environment: Enterprise Maven Project
> Wildfly 11
> Eclipse Link 2.7.1 (2.6.3 and 2.64 were also tested)
> Reporter: Alessandro Moscatelli
> Assignee: Scott Marlow
> Fix For: 12.0.0.Final
>
>
> Following :
> https://docs.jboss.org/author/display/WFLY/JPA+Reference+Guide#JPAReferen...
> When you try to persist ANY entity (located in ejb, or jar or anywhere you want) if such entity is not listed in persistence.xml you'll get a :
> Caused by: javax.ejb.EJBException: java.lang.IllegalArgumentException: Object: org.visiontech.optoplus.entity.Provider[ id=null ] is not a known Entity type
> If I list such entity in persistence.xml the error is gone and the entity is persisted.
> Inside standalone.xml I used :
> <system-properties>
> ...
> <property name="eclipselink.archive.factory" value="org.jipijapa.eclipselink.JBossArchiveFactoryImpl"/>
> </system-properties>
> Is this a problem related to the last version (11 Final) of jipijapa.eclipselink ?
> I found several topic stating that what I done worked with Wildfly 10 and older version of jipijapa.
> I tried several combination of older jipijapa and eclipselink versions without success.
> I have about 130 entities in my probject, I'd REALLY love not to enlist them all.
> My persistence.xml :
> <persistence-unit name="optoplus">
> <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
> <jta-data-source>java:/jdbc/db_optoplus</jta-data-source>
> <exclude-unlisted-classes>false</exclude-unlisted-classes>
> </persistence-unit>
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (WFLY-9878) EclipseLink Entity Scanning broken in Wildfly 11
by Alessandro Moscatelli (JIRA)
[ https://issues.jboss.org/browse/WFLY-9878?page=com.atlassian.jira.plugin.... ]
Alessandro Moscatelli commented on WFLY-9878:
---------------------------------------------
The only difference is in :
" <property name=\"jboss.as.jpa.providerModule\" value=\"org.eclipse.persistence:test\"/>"
What is this ? I didn't find this property in the documentation.
> EclipseLink Entity Scanning broken in Wildfly 11
> ------------------------------------------------
>
> Key: WFLY-9878
> URL: https://issues.jboss.org/browse/WFLY-9878
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 11.0.0.Final
> Environment: Enterprise Maven Project
> Wildfly 11
> Eclipse Link 2.7.1 (2.6.3 and 2.64 were also tested)
> Reporter: Alessandro Moscatelli
> Assignee: Scott Marlow
> Fix For: 12.0.0.Final
>
>
> Following :
> https://docs.jboss.org/author/display/WFLY/JPA+Reference+Guide#JPAReferen...
> When you try to persist ANY entity (located in ejb, or jar or anywhere you want) if such entity is not listed in persistence.xml you'll get a :
> Caused by: javax.ejb.EJBException: java.lang.IllegalArgumentException: Object: org.visiontech.optoplus.entity.Provider[ id=null ] is not a known Entity type
> If I list such entity in persistence.xml the error is gone and the entity is persisted.
> Inside standalone.xml I used :
> <system-properties>
> ...
> <property name="eclipselink.archive.factory" value="org.jipijapa.eclipselink.JBossArchiveFactoryImpl"/>
> </system-properties>
> Is this a problem related to the last version (11 Final) of jipijapa.eclipselink ?
> I found several topic stating that what I done worked with Wildfly 10 and older version of jipijapa.
> I tried several combination of older jipijapa and eclipselink versions without success.
> I have about 130 entities in my probject, I'd REALLY love not to enlist them all.
> My persistence.xml :
> <persistence-unit name="optoplus">
> <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
> <jta-data-source>java:/jdbc/db_optoplus</jta-data-source>
> <exclude-unlisted-classes>false</exclude-unlisted-classes>
> </persistence-unit>
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (WFLY-9878) EclipseLink Entity Scanning broken in Wildfly 11
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-9878?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-9878:
------------------------------------
Years ago, we had this problem but I'm not aware of it currently happening in WildFly 11+. I do know that a very simple unit test is working [https://github.com/wildfly/wildfly/tree/master/testsuite/compat/src/test/...], which has the persistence.xml hard coded as a string variable in the test:
{code}
private static final String persistence_xml =
"<?xml version=\"1.0\" encoding=\"UTF-8\"?> " +
"<persistence xmlns=\"http://java.sun.com/xml/ns/persistence\" version=\"1.0\">" +
" <persistence-unit name=\"hibernate3_pc\">" +
"<provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>"+
" <description>TopLink Persistence Unit." +
" </description>" +
" <jta-data-source>java:jboss/datasources/ExampleDS</jta-data-source>" +
" <properties>" +
" <property name=\"jboss.as.jpa.providerModule\" value=\"org.eclipse.persistence:test\"/>" +
" <property name=\"eclipselink.ddl-generation\" value=\"drop-and-create-tables\"/>"+
" </properties>" +
" </persistence-unit>" +
"</persistence>";
{code}
I'm not sure if the org.eclipse.persistence.internal.jpa.deployment.ArchiveFactoryImpl logging would help identify the root cause or actually debugging the org.jipijapa.eclipselink.JBossArchiveFactoryImpl (with your application deployment). If you want to try to debug, I can give you some pointers to make sense of how some of the code (e.g. acts as a bridge between the WildFly virtual file system (VFS) and EclipseLink ArchiveFactoryImpl).
> EclipseLink Entity Scanning broken in Wildfly 11
> ------------------------------------------------
>
> Key: WFLY-9878
> URL: https://issues.jboss.org/browse/WFLY-9878
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 11.0.0.Final
> Environment: Enterprise Maven Project
> Wildfly 11
> Eclipse Link 2.7.1 (2.6.3 and 2.64 were also tested)
> Reporter: Alessandro Moscatelli
> Assignee: Scott Marlow
> Fix For: 12.0.0.Final
>
>
> Following :
> https://docs.jboss.org/author/display/WFLY/JPA+Reference+Guide#JPAReferen...
> When you try to persist ANY entity (located in ejb, or jar or anywhere you want) if such entity is not listed in persistence.xml you'll get a :
> Caused by: javax.ejb.EJBException: java.lang.IllegalArgumentException: Object: org.visiontech.optoplus.entity.Provider[ id=null ] is not a known Entity type
> If I list such entity in persistence.xml the error is gone and the entity is persisted.
> Inside standalone.xml I used :
> <system-properties>
> ...
> <property name="eclipselink.archive.factory" value="org.jipijapa.eclipselink.JBossArchiveFactoryImpl"/>
> </system-properties>
> Is this a problem related to the last version (11 Final) of jipijapa.eclipselink ?
> I found several topic stating that what I done worked with Wildfly 10 and older version of jipijapa.
> I tried several combination of older jipijapa and eclipselink versions without success.
> I have about 130 entities in my probject, I'd REALLY love not to enlist them all.
> My persistence.xml :
> <persistence-unit name="optoplus">
> <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
> <jta-data-source>java:/jdbc/db_optoplus</jta-data-source>
> <exclude-unlisted-classes>false</exclude-unlisted-classes>
> </persistence-unit>
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months