[JBoss JIRA] (WFLY-4444) Ability to set WSDL URL
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/WFLY-4444?page=com.atlassian.jira.plugin.... ]
Alessio Soldano commented on WFLY-4444:
---------------------------------------
To use the jbossws-cxf.xml, you need to enable the Spring integration, which is not the suggested approach (and is being deprecated in next JBossWS 5).
As I previously said, I think at this point it would be great if you could provide me/us some kind of reproducer or a simplified version of you app that fails in your environment, so that we can take a look.
> Ability to set WSDL URL
> -----------------------
>
> Key: WFLY-4444
> URL: https://issues.jboss.org/browse/WFLY-4444
> Project: WildFly
> Issue Type: Feature Request
> Components: Web Services
> Affects Versions: 8.2.0.Final
> Reporter: John Ament
> Assignee: Alessio Soldano
>
> There's no way to correctly set a WSDL URL. The properties are:
> {code}
> <modify-wsdl-address>true</modify-wsdl-address>
> <wsdl-host>${public.app.host:localhost}</wsdl-host>
> <wsdl-port>${public.http.port:80}</wsdl-port>
> <wsdl-secure-port>${public.https.port:443}</wsdl-secure-port>
> {code}
> We need a way to set the WSDL URL, regardless of the protocol used. The issue being that our app servers run on HTTP, but the incoming request to the first load balancer is over HTTPS. The result is that the WSDL generated includes http://public-host:80/ instead of https://public-host:443/
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-4416) Cannot obtain DOMImplementationRegistry instance
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/WFLY-4416?page=com.atlassian.jira.plugin.... ]
Thomas Diesler edited comment on WFLY-4416 at 3/25/15 4:48 AM:
---------------------------------------------------------------
A deployment cannot load the default DOM impl through the DOMImplementationRegistry because it has no wire to the jdk module that exports com/sun/org/apache/xerces/internal/dom.
I wonder how the notion of the sun.jdk module works with other jdks. I'd assume that the internal paths are likely to be different.
was (Author: thomas.diesler):
A deployment cannot load the default DOM impl through the DOMImplementationRegistry because it has no wire to sun.jdk.
I wonder how the notion of the sun.jdk module works with other jdks. I'd assume that the internal paths are likely to be different.
> Cannot obtain DOMImplementationRegistry instance
> ------------------------------------------------
>
> Key: WFLY-4416
> URL: https://issues.jboss.org/browse/WFLY-4416
> Project: WildFly
> Issue Type: Bug
> Components: XML Frameworks
> Affects Versions: 8.2.0.Final
> Reporter: Thomas Diesler
> Assignee: Jason Greene
>
> {code}
> testDOMImplementationRegistry(org.jboss.as.test.smoke.xml.DOMImplementationRegistryTestCase) Time elapsed: 0.09 sec <<< ERROR!
> java.lang.ClassNotFoundException: com.sun.org.apache.xerces.internal.dom.DOMXSImplementationSourceImpl from [Module "deployment.dom-registry-test:main" from Service Module Loader]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134)
> at org.w3c.dom.bootstrap.DOMImplementationRegistry.newInstance(DOMImplementationRegistry.java:182)
> at org.jboss.as.test.smoke.xml.DOMImplementationRegistryTestCase.testDOMImplementationRegistry(DOMImplementationRegistryTestCase.java:52)
> {code}
> CrossRef: https://github.com/wildfly-extras/wildfly-camel/issues/391
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-4424) NullPointerException in AbstractCommonConfigResolver.resolveEndpointConfig
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/WFLY-4424?page=com.atlassian.jira.plugin.... ]
Alessio Soldano commented on WFLY-4424:
---------------------------------------
I figured out this is sometimes reproducible also by starting a WildFly instance already having ws deployments. So I'm increasing the priority. This should likely block the Beta release; if the required wildfly-core upgrade can't be done in time, I suggest we apply a simple workaround in wildfly (that is, use actual hex phase values in WSDeploymentActivator instead of constants to force proper DUP ordering).
> NullPointerException in AbstractCommonConfigResolver.resolveEndpointConfig
> --------------------------------------------------------------------------
>
> Key: WFLY-4424
> URL: https://issues.jboss.org/browse/WFLY-4424
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Reporter: Gytis Trikleris
> Assignee: Alessio Soldano
> Fix For: 9.0.0.Beta1
>
>
> Lately we started to get following exception in our XTS tests:
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.deployment.unit."xtstest.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."xtstest.war".PARSE: WFLYSRV0153: Failed to process phase PARSE of deployment "xtstest.war"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:163)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> Caused by: java.lang.NullPointerException
> at org.jboss.ws.common.configuration.AbstractCommonConfigResolver.resolveEndpointConfig(AbstractCommonConfigResolver.java:129)
> at org.jboss.as.webservices.deployers.WSIntegrationProcessorJAXWS_HANDLER.processAnnotation(WSIntegrationProcessorJAXWS_HANDLER.java:95)
> at org.jboss.as.webservices.deployers.AbstractIntegrationProcessorJAXWS.deploy(AbstractIntegrationProcessorJAXWS.java:74)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156)
> ... 5 more
> {code}
> It is intermittent and seems to be caused by some sort of race condition.
> It started to happen once this commit was introduced: https://github.com/wildfly/wildfly/commit/c0c1e82d8472e1b29c679380d5e0aea...
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-4424) NullPointerException in AbstractCommonConfigResolver.resolveEndpointConfig
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/WFLY-4424?page=com.atlassian.jira.plugin.... ]
Alessio Soldano updated WFLY-4424:
----------------------------------
Priority: Blocker (was: Major)
> NullPointerException in AbstractCommonConfigResolver.resolveEndpointConfig
> --------------------------------------------------------------------------
>
> Key: WFLY-4424
> URL: https://issues.jboss.org/browse/WFLY-4424
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Reporter: Gytis Trikleris
> Assignee: Alessio Soldano
> Priority: Blocker
> Fix For: 9.0.0.Beta1
>
>
> Lately we started to get following exception in our XTS tests:
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.deployment.unit."xtstest.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."xtstest.war".PARSE: WFLYSRV0153: Failed to process phase PARSE of deployment "xtstest.war"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:163)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> Caused by: java.lang.NullPointerException
> at org.jboss.ws.common.configuration.AbstractCommonConfigResolver.resolveEndpointConfig(AbstractCommonConfigResolver.java:129)
> at org.jboss.as.webservices.deployers.WSIntegrationProcessorJAXWS_HANDLER.processAnnotation(WSIntegrationProcessorJAXWS_HANDLER.java:95)
> at org.jboss.as.webservices.deployers.AbstractIntegrationProcessorJAXWS.deploy(AbstractIntegrationProcessorJAXWS.java:74)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156)
> ... 5 more
> {code}
> It is intermittent and seems to be caused by some sort of race condition.
> It started to happen once this commit was introduced: https://github.com/wildfly/wildfly/commit/c0c1e82d8472e1b29c679380d5e0aea...
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-4424) NullPointerException in AbstractCommonConfigResolver.resolveEndpointConfig
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/WFLY-4424?page=com.atlassian.jira.plugin.... ]
Alessio Soldano updated WFLY-4424:
----------------------------------
Fix Version/s: 9.0.0.Beta1
> NullPointerException in AbstractCommonConfigResolver.resolveEndpointConfig
> --------------------------------------------------------------------------
>
> Key: WFLY-4424
> URL: https://issues.jboss.org/browse/WFLY-4424
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Reporter: Gytis Trikleris
> Assignee: Alessio Soldano
> Fix For: 9.0.0.Beta1
>
>
> Lately we started to get following exception in our XTS tests:
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.deployment.unit."xtstest.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."xtstest.war".PARSE: WFLYSRV0153: Failed to process phase PARSE of deployment "xtstest.war"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:163)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> Caused by: java.lang.NullPointerException
> at org.jboss.ws.common.configuration.AbstractCommonConfigResolver.resolveEndpointConfig(AbstractCommonConfigResolver.java:129)
> at org.jboss.as.webservices.deployers.WSIntegrationProcessorJAXWS_HANDLER.processAnnotation(WSIntegrationProcessorJAXWS_HANDLER.java:95)
> at org.jboss.as.webservices.deployers.AbstractIntegrationProcessorJAXWS.deploy(AbstractIntegrationProcessorJAXWS.java:74)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156)
> ... 5 more
> {code}
> It is intermittent and seems to be caused by some sort of race condition.
> It started to happen once this commit was introduced: https://github.com/wildfly/wildfly/commit/c0c1e82d8472e1b29c679380d5e0aea...
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-4416) Cannot obtain DOMImplementationRegistry instance
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/WFLY-4416?page=com.atlassian.jira.plugin.... ]
Thomas Diesler commented on WFLY-4416:
--------------------------------------
A deployment cannot load the default DOM impl through the DOMImplementationRegistry because it has no wire to sun.jdk.
I wonder how the notion of the sun.jdk module works with other jdks. I'd assume that the internal paths are likely to be different.
> Cannot obtain DOMImplementationRegistry instance
> ------------------------------------------------
>
> Key: WFLY-4416
> URL: https://issues.jboss.org/browse/WFLY-4416
> Project: WildFly
> Issue Type: Bug
> Components: XML Frameworks
> Affects Versions: 8.2.0.Final
> Reporter: Thomas Diesler
> Assignee: Jason Greene
>
> {code}
> testDOMImplementationRegistry(org.jboss.as.test.smoke.xml.DOMImplementationRegistryTestCase) Time elapsed: 0.09 sec <<< ERROR!
> java.lang.ClassNotFoundException: com.sun.org.apache.xerces.internal.dom.DOMXSImplementationSourceImpl from [Module "deployment.dom-registry-test:main" from Service Module Loader]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134)
> at org.w3c.dom.bootstrap.DOMImplementationRegistry.newInstance(DOMImplementationRegistry.java:182)
> at org.jboss.as.test.smoke.xml.DOMImplementationRegistryTestCase.testDOMImplementationRegistry(DOMImplementationRegistryTestCase.java:52)
> {code}
> CrossRef: https://github.com/wildfly-extras/wildfly-camel/issues/391
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFCORE-601) Boot sometimes fails on restart when deployments are present in the deployments directory and the deployment scanner is in use
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-601?page=com.atlassian.jira.plugin... ]
ehsavoie Hugonnet edited comment on WFCORE-601 at 3/25/15 2:44 AM:
-------------------------------------------------------------------
Hum I should not answer when in PTO.
Does the war needs the datasource ?
was (Author: ehugonnet):
WFCORE-232 might be similar. There is a PR almost finished
> Boot sometimes fails on restart when deployments are present in the deployments directory and the deployment scanner is in use
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-601
> URL: https://issues.jboss.org/browse/WFCORE-601
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Reporter: Stuart Douglas
> Assignee: Stuart Douglas
>
> I observed this today, looks to be some kind of race in the deployment scanner on boot
> {code}
> 21:52:08,618 INFO [org.jboss.modules] (main) JBoss Modules version 1.4.1.Final
> 21:52:10,370 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.4.Final
> 21:52:10,440 INFO [org.jboss.as] (MSC service thread 1-6) WFLYSRV0049: WildFly Full 9.0.0.Alpha2-SNAPSHOT (WildFly Core 1.0.0.Alpha19) starting
> 21:52:11,390 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 20) WFLYCTL0028: Attribute enabled is deprecated, and it might be removed in future version!
> 21:52:11,409 INFO [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) WFLYDS0015: Re-attempting failed deployment mysql-ds.xml
> 21:52:11,413 INFO [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) WFLYDS0015: Re-attempting failed deployment wildfly-ee7.war
> 21:52:11,488 INFO [org.jboss.as.repository] (ServerService Thread Pool -- 3) WFLYDR0001: Content added at location /Users/stuart/workspace/wildfly/build/target/wildfly-9.0.0.Alpha2-SNAPSHOT/standalone/data/content/48/032d14f289775249a004205c059588ab0f44d4/content
> 21:52:11,504 INFO [org.jboss.as.repository] (ServerService Thread Pool -- 3) WFLYDR0001: Content added at location /Users/stuart/workspace/wildfly/build/target/wildfly-9.0.0.Alpha2-SNAPSHOT/standalone/data/content/c6/7babde4791697ddc6509fbd43ba1ec25952d47/content
> 21:52:11,506 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 3) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "wildfly-ee7.war")]) - failure description: "WFLYCTL0212: Duplicate resource [(\"deployment\" => \"wildfly-ee7.war\")]"
> 21:52:11,509 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) "WFLYCTL0193: Failed executing subsystem deployment-scanner boot operations"
> 21:52:11,512 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("parallel-subsystem-boot") failed - address: ([]) - failure description: "\"WFLYCTL0193: Failed executing subsystem deployment-scanner boot operations\""
> 21:52:11,514 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> 21:52:11,514 INFO [org.jboss.as.server] (Thread-2) WFLYSRV0220: Server shutdown has been requested.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-4463) IIOPNamingTestCase is failing when run on IBM JDK
by Tomaz Cerar (JIRA)
Tomaz Cerar created WFLY-4463:
---------------------------------
Summary: IIOPNamingTestCase is failing when run on IBM JDK
Key: WFLY-4463
URL: https://issues.jboss.org/browse/WFLY-4463
Project: WildFly
Issue Type: Bug
Components: IIOP
Affects Versions: 9.0.0.Alpha1
Environment: IBM JDK7
Reporter: Tomaz Cerar
Assignee: Tomasz Adamski
IIOPNamingTestCase failing with errors like
{noformat}
java.lang.ClassCastException: Unable to load class: org.jboss.as.test.integration.ejb.iiop.naming._IIOPNamingHome_Stub
at com.ibm.rmi.javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:372)
at javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:164)
at org.jboss.as.test.integration.ejb.iiop.naming.IIOPNamingTestCase.testCorbalocInvocationWithDDOverride(IIOPNamingTestCase.java:176)
{noformat}
it looks exactly like WFLY-1783 that was fixed before. Maybe and oversight with new orb impl.
see http://brontes.lab.eng.brq.redhat.com/viewType.html?buildTypeId=WF_Master...
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-4444) Ability to set WSDL URL
by John Ament (JIRA)
[ https://issues.jboss.org/browse/WFLY-4444?page=com.atlassian.jira.plugin.... ]
John Ament commented on WFLY-4444:
----------------------------------
[~asoldano] any idea?
> Ability to set WSDL URL
> -----------------------
>
> Key: WFLY-4444
> URL: https://issues.jboss.org/browse/WFLY-4444
> Project: WildFly
> Issue Type: Feature Request
> Components: Web Services
> Affects Versions: 8.2.0.Final
> Reporter: John Ament
> Assignee: Alessio Soldano
>
> There's no way to correctly set a WSDL URL. The properties are:
> {code}
> <modify-wsdl-address>true</modify-wsdl-address>
> <wsdl-host>${public.app.host:localhost}</wsdl-host>
> <wsdl-port>${public.http.port:80}</wsdl-port>
> <wsdl-secure-port>${public.https.port:443}</wsdl-secure-port>
> {code}
> We need a way to set the WSDL URL, regardless of the protocol used. The issue being that our app servers run on HTTP, but the incoming request to the first load balancer is over HTTPS. The result is that the WSDL generated includes http://public-host:80/ instead of https://public-host:443/
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-4461) CDI Interceptor is not called in EJB Schedule
by Janario Oliveira (JIRA)
[ https://issues.jboss.org/browse/WFLY-4461?page=com.atlassian.jira.plugin.... ]
Janario Oliveira commented on WFLY-4461:
----------------------------------------
Thanks Stuart
> CDI Interceptor is not called in EJB Schedule
> ---------------------------------------------
>
> Key: WFLY-4461
> URL: https://issues.jboss.org/browse/WFLY-4461
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 8.2.0.Final
> Reporter: Janario Oliveira
> Assignee: Stuart Douglas
>
> I have defined a CDI interceptor as following:
> @Interceptor
> @MyIntercept
> public class MyInterceptor {
> @AroundInvoke
> public Object intercept(InvocationContext context) throws Exception {
> LOG.info("Call {}.{}",
> context.getMethod().getDeclaringClass().getName(), context.getMethod().getName());
> return context.proceed();
> }
> }
> @InterceptorBinding
> @Retention(RetentionPolicy.RUNTIME)
> @Target({ElementType.METHOD, ElementType.TYPE})
> public @interface MyIntercept {}
> And declared it in MyService
> @Singleton
> @MyIntercept
> public class MyService {
> @Schedule(second = "0/10", minute = "*", hour = "*", persistent = false)
> public void schedule() {
> //... do something
> }
> public void manualCall() {
> //... do something
> }
> }
> The interceptor was never called to schedule method but when call the manualCall method the interceptor was invoked.
> I've also tested with weld-core-impl 2.2.9.Final and it didn't work.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months