5:38 p.m.
All webservice_proxy_* quickstarts are broken
---------------------------------------------
Key: JBESB-3412
URL: https://jira.jboss.org/browse/JBESB-3412
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Examples, Web Services
Environment: JDK 1.5 + AS 4.2.3 and JDK 1.6 + AS 5.1.0
Reporter: David Ward
Priority: Blocker
Fix For: 4.9
Each of the webservice_proxy_* quickstarts are broken in some way.
webservice_proxy_basic, webservice_proxy_security and webservice_proxy_versioning all have
problem with their WSDL contracts being empty from the http//localhost:8080/contract/ web
application. Light debugging showed that the reason for this is that
ContractProviderLifecycleResource, while having it's map being propertly populated
with the appropriate lifecycle resource (deployment) ID + ContractProvider instance at
deployment, is returning null when the HttpGatewayServlet attempts to get at it's
appropriate ContractProvider. The reason is that during the thread of execution behind
the HttpGatewayServlet, when calling ContractProviderLifecycleResource.buildKey(svc_cat,
svc_name), LifecycleResourceManager.getSingleton().getIdentity() is returning DEFAULT-ID
(or whatever it's called) instead of the actual deployment ID. This *USED* to work,
so I don't know what changed environment-wise. webservice_proxy_routed doesn't
provide a contract (no HTTP endpoints), so it's N/A to that quickstart.
webservice_proxy_routed doesn't provide a contract either (no HTTP endpoints), however
it has a different problem. It appears the work done in JBESB-3372 ("Move SOAP
services away from JBossWS-Native implementation") has a bug when using
JBossWS-Native. I thought the purpose was that both the Native and CXF stacks should
work. If only the CXF stack should work, we shouldn't release ESB .org with Native.
Anyway, after lightly looking at the code changes, it appears that there is a problem with
the mappings being done. Specifically the same QName for Operation/Binding is being
reused everywhere, even if there is more than one. When you run the quickstart with
"ant saygoodbye", it work. When you run the quickstart with "ant
sayhello" it breaks. This is because the goodbye QName is what was used. For
example, "{http://webservice_proxy_routed/goodbye}GoodbyeBinding" and
"{http://webservice_proxy_routed/goodbye}sayGoodbye". This is fine for
"ant rungoodbye", but when you run "ant runhello" you get, "ERROR
[SOAPFaultHelperJAXWS] SOAP request exception
org.jboss.ws.core.CommonSOAPFaultException: Endpoint
{http://webservice_proxy_routed/goodbye}GoodbyePort does not contain operation meta data
for: {http://webservice_proxy_routed/hello}sayHello". So, obviously the mapping work
done during initialization is busted in that it won't support more than one. In fact,
looking at the deployment INFO being logged again, you will see the set of
"[SOAPProxy] mapped abc [...] to xyz [...]" mappings twice, but both sets for
GOODBYE. Nothing for HELLO.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:40 p.m.
New subject: [JBoss JIRA] Updated: (JBESB-3412) All webservice_proxy_* quickstarts are broken
[
https://jira.jboss.org/browse/JBESB-3412?page=com.atlassian.jira.plugin.s...
]
David Ward updated JBESB-3412:
------------------------------
Attachment: webservice_proxy_routed.log
webservice_proxy_routed.log shows the parsing/mapping being stuck on "goodbye"
and ignoring "hello".
All webservice_proxy_* quickstarts are broken
---------------------------------------------
Key: JBESB-3412
URL: https://jira.jboss.org/browse/JBESB-3412
Project: JBoss ESB
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Examples, Web Services
Environment: JDK 1.5 + AS 4.2.3 and JDK 1.6 + AS 5.1.0
Reporter: David Ward
Priority: Blocker
Fix For: 4.9
Attachments: webservice_proxy_routed.log
Each of the webservice_proxy_* quickstarts are broken in some way.
webservice_proxy_basic, webservice_proxy_security and webservice_proxy_versioning all
have problem with their WSDL contracts being empty from the http//localhost:8080/contract/
web application. Light debugging showed that the reason for this is that
ContractProviderLifecycleResource, while having it's map being propertly populated
with the appropriate lifecycle resource (deployment) ID + ContractProvider instance at
deployment, is returning null when the HttpGatewayServlet attempts to get at it's
appropriate ContractProvider. The reason is that during the thread of execution behind
the HttpGatewayServlet, when calling ContractProviderLifecycleResource.buildKey(svc_cat,
svc_name), LifecycleResourceManager.getSingleton().getIdentity() is returning DEFAULT-ID
(or whatever it's called) instead of the actual deployment ID. This *USED* to work,
so I don't know what changed environment-wise. webservice_proxy_routed doesn't
provide a contract (no HTTP endpoints), so it's N/A to that quickstart.
webservice_proxy_routed doesn't provide a contract either (no HTTP endpoints),
however it has a different problem. It appears the work done in JBESB-3372 ("Move
SOAP services away from JBossWS-Native implementation") has a bug when using
JBossWS-Native. I thought the purpose was that both the Native and CXF stacks should
work. If only the CXF stack should work, we shouldn't release ESB .org with Native.
Anyway, after lightly looking at the code changes, it appears that there is a problem with
the mappings being done. Specifically the same QName for Operation/Binding is being
reused everywhere, even if there is more than one. When you run the quickstart with
"ant saygoodbye", it work. When you run the quickstart with "ant
sayhello" it breaks. This is because the goodbye QName is what was used. For
example, "{http://webservice_proxy_routed/goodbye}GoodbyeBinding" and
"{http://webservice_proxy_routed/goodbye}sayGoodbye". This is fine for
"ant rungoodbye", but when you run "ant runhello" you get, "ERROR
[SOAPFaultHelperJAXWS] SOAP request exception
org.jboss.ws.core.CommonSOAPFaultException: Endpoint
{http://webservice_proxy_routed/goodbye}GoodbyePort does not contain operation meta data
for: {http://webservice_proxy_routed/hello}sayHello". So, obviously the mapping work
done during initialization is busted in that it won't support more than one. In fact,
looking at the deployment INFO being logged again, you will see the set of
"[SOAPProxy] mapped abc [...] to xyz [...]" mappings twice, but both sets for
GOODBYE. Nothing for HELLO.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:04 p.m.
New subject: [JBoss JIRA] Updated: (JBESB-3412) All webservice_proxy_* quickstarts are broken
[
https://jira.jboss.org/browse/JBESB-3412?page=com.atlassian.jira.plugin.s...
]
David Ward updated JBESB-3412:
------------------------------
Description:
Each of the webservice_proxy_* quickstarts are broken in some way.
webservice_proxy_basic, webservice_proxy_security and webservice_proxy_versioning all have
problem with their WSDL contracts being empty from the http//localhost:8080/contract/ web
application. Light debugging showed that the reason for this is that
ContractProviderLifecycleResource, while having it's map being propertly populated
with the appropriate lifecycle resource (deployment) ID + ContractProvider instance at
deployment, is returning null when the HttpGatewayServlet attempts to get at it's
appropriate ContractProvider. The reason is that during the thread of execution behind
the HttpGatewayServlet, when calling ContractProviderLifecycleResource.buildKey(svc_cat,
svc_name), LifecycleResourceManager.getSingleton().getIdentity() is returning DEFAULT-ID
(or whatever it's called) instead of the actual deployment ID. This *USED* to work,
so I don't know what changed environment-wise. webservice_proxy_routed doesn't
provide a contract (no HTTP endpoints), so it's N/A to that quickstart.
webservice_proxy_routed has a different problem. It appears the work done in JBESB-3372
("Move SOAP services away from JBossWS-Native implementation") has a bug when
using JBossWS-Native. I thought the purpose was that both the Native and CXF stacks
should work. If only the CXF stack should work, we shouldn't release ESB .org with
Native. Anyway, after lightly looking at the code changes, it appears that there is a
problem with the mappings being done. Specifically the same QName for Operation/Binding
is being reused everywhere, even if there is more than one. When you run the quickstart
with "ant saygoodbye", it work. When you run the quickstart with "ant
sayhello" it breaks. This is because the goodbye QName is what was used. For
example, "{http://webservice_proxy_routed/goodbye}GoodbyeBinding" and
"{http://webservice_proxy_routed/goodbye}sayGoodbye". This is fine for
"ant rungoodbye", but when you run "ant runhello" you get, "ERROR
[SOAPFaultHelperJAXWS] SOAP request exception
org.jboss.ws.core.CommonSOAPFaultException: Endpoint
{http://webservice_proxy_routed/goodbye}GoodbyePort does not contain operation meta data
for: {http://webservice_proxy_routed/hello}sayHello". So, obviously the mapping work
done during initialization is busted in that it won't support more than one. In fact,
looking at the deployment INFO being logged again, you will see the set of
"[SOAPProxy] mapped abc [...] to xyz [...]" mappings twice, but both sets for
GOODBYE. Nothing for HELLO.
was:
Each of the webservice_proxy_* quickstarts are broken in some way.
webservice_proxy_basic, webservice_proxy_security and webservice_proxy_versioning all have
problem with their WSDL contracts being empty from the http//localhost:8080/contract/ web
application. Light debugging showed that the reason for this is that
ContractProviderLifecycleResource, while having it's map being propertly populated
with the appropriate lifecycle resource (deployment) ID + ContractProvider instance at
deployment, is returning null when the HttpGatewayServlet attempts to get at it's
appropriate ContractProvider. The reason is that during the thread of execution behind
the HttpGatewayServlet, when calling ContractProviderLifecycleResource.buildKey(svc_cat,
svc_name), LifecycleResourceManager.getSingleton().getIdentity() is returning DEFAULT-ID
(or whatever it's called) instead of the actual deployment ID. This *USED* to work,
so I don't know what changed environment-wise. webservice_proxy_routed doesn't
provide a contract (no HTTP endpoints), so it's N/A to that quickstart.
webservice_proxy_routed doesn't provide a contract either (no HTTP endpoints), however
it has a different problem. It appears the work done in JBESB-3372 ("Move SOAP
services away from JBossWS-Native implementation") has a bug when using
JBossWS-Native. I thought the purpose was that both the Native and CXF stacks should
work. If only the CXF stack should work, we shouldn't release ESB .org with Native.
Anyway, after lightly looking at the code changes, it appears that there is a problem with
the mappings being done. Specifically the same QName for Operation/Binding is being
reused everywhere, even if there is more than one. When you run the quickstart with
"ant saygoodbye", it work. When you run the quickstart with "ant
sayhello" it breaks. This is because the goodbye QName is what was used. For
example, "{http://webservice_proxy_routed/goodbye}GoodbyeBinding" and
"{http://webservice_proxy_routed/goodbye}sayGoodbye". This is fine for
"ant rungoodbye", but when you run "ant runhello" you get, "ERROR
[SOAPFaultHelperJAXWS] SOAP request exception
org.jboss.ws.core.CommonSOAPFaultException: Endpoint
{http://webservice_proxy_routed/goodbye}GoodbyePort does not contain operation meta data
for: {http://webservice_proxy_routed/hello}sayHello". So, obviously the mapping work
done during initialization is busted in that it won't support more than one. In fact,
looking at the deployment INFO being logged again, you will see the set of
"[SOAPProxy] mapped abc [...] to xyz [...]" mappings twice, but both sets for
GOODBYE. Nothing for HELLO.
All webservice_proxy_* quickstarts are broken
---------------------------------------------
Key: JBESB-3412
URL: https://jira.jboss.org/browse/JBESB-3412
Project: JBoss ESB
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Examples, Web Services
Environment: JDK 1.5 + AS 4.2.3 and JDK 1.6 + AS 5.1.0
Reporter: David Ward
Priority: Blocker
Fix For: 4.9
Attachments: webservice_proxy_routed.log
Each of the webservice_proxy_* quickstarts are broken in some way.
webservice_proxy_basic, webservice_proxy_security and webservice_proxy_versioning all
have problem with their WSDL contracts being empty from the http//localhost:8080/contract/
web application. Light debugging showed that the reason for this is that
ContractProviderLifecycleResource, while having it's map being propertly populated
with the appropriate lifecycle resource (deployment) ID + ContractProvider instance at
deployment, is returning null when the HttpGatewayServlet attempts to get at it's
appropriate ContractProvider. The reason is that during the thread of execution behind
the HttpGatewayServlet, when calling ContractProviderLifecycleResource.buildKey(svc_cat,
svc_name), LifecycleResourceManager.getSingleton().getIdentity() is returning DEFAULT-ID
(or whatever it's called) instead of the actual deployment ID. This *USED* to work,
so I don't know what changed environment-wise. webservice_proxy_routed doesn't
provide a contract (no HTTP endpoints), so it's N/A to that quickstart.
webservice_proxy_routed has a different problem. It appears the work done in JBESB-3372
("Move SOAP services away from JBossWS-Native implementation") has a bug when
using JBossWS-Native. I thought the purpose was that both the Native and CXF stacks
should work. If only the CXF stack should work, we shouldn't release ESB .org with
Native. Anyway, after lightly looking at the code changes, it appears that there is a
problem with the mappings being done. Specifically the same QName for Operation/Binding
is being reused everywhere, even if there is more than one. When you run the quickstart
with "ant saygoodbye", it work. When you run the quickstart with "ant
sayhello" it breaks. This is because the goodbye QName is what was used. For
example, "{http://webservice_proxy_routed/goodbye}GoodbyeBinding" and
"{http://webservice_proxy_routed/goodbye}sayGoodbye". This is fine for
"ant rungoodbye", but when you run "ant runhello" you get, "ERROR
[SOAPFaultHelperJAXWS] SOAP request exception
org.jboss.ws.core.CommonSOAPFaultException: Endpoint
{http://webservice_proxy_routed/goodbye}GoodbyePort does not contain operation meta data
for: {http://webservice_proxy_routed/hello}sayHello". So, obviously the mapping work
done during initialization is busted in that it won't support more than one. In fact,
looking at the deployment INFO being logged again, you will see the set of
"[SOAPProxy] mapped abc [...] to xyz [...]" mappings twice, but both sets for
GOODBYE. Nothing for HELLO.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:08 p.m.
New subject: [JBoss JIRA] Updated: (JBESB-3412) All webservice_proxy_* quickstarts are broken
[
https://jira.jboss.org/browse/JBESB-3412?page=com.atlassian.jira.plugin.s...
]
David Ward updated JBESB-3412:
------------------------------
Description:
Each of the webservice_proxy_* quickstarts are broken in some way.
webservice_proxy_basic, webservice_proxy_security and webservice_proxy_versioning all have
problem with their WSDL contracts being empty from the http//localhost:8080/contract/ web
application. Light debugging showed that the reason for this is that
ContractProviderLifecycleResource, while having it's map being propertly populated
with the appropriate lifecycle resource (deployment) ID + ContractProvider instance at
deployment, is returning null when the HttpGatewayServlet attempts to get at it's
appropriate ContractProvider. The reason is that during the thread of execution behind
the HttpGatewayServlet, when calling ContractProviderLifecycleResource.buildKey(svc_cat,
svc_name), LifecycleResourceManager.getSingleton().getIdentity() is returning DEFAULT-ID
(or whatever it's called) instead of the actual deployment ID. This *USED* to work,
so I don't know what changed environment-wise. webservice_proxy_routed doesn't
provide a contract (no HTTP endpoints), so it's N/A to that quickstart.
webservice_proxy_routed has a different problem. It appears the work done in JBESB-3372
("Move SOAP services away from JBossWS-Native implementation") has a bug when
using JBossWS-Native. I thought the purpose was that both the Native and CXF stacks
should work. If only the CXF stack should work, we shouldn't release ESB .org with
Native. Anyway, after lightly looking at the code changes, it appears that there is a
problem with the mappings being done. Specifically the same QName for Operation/Binding
is being reused everywhere, even if there is more than one. When you run the quickstart
with "ant saygoodbye", it work. When you run the quickstart with "ant
sayhello" it breaks. This is because the goodbye QName is what was used. For
example, "{http://webservice_proxy_routed/goodbye}GoodbyeBinding" and
"{http://webservice_proxy_routed/goodbye}sayGoodbye". This is fine for
"ant rungoodbye", but when you run "ant runhello" you get, "ERROR
[SOAPFaultHelperJAXWS] SOAP request exception
org.jboss.ws.core.CommonSOAPFaultException: Endpoint
{http://webservice_proxy_routed/goodbye}GoodbyePort does not contain operation meta data
for: {http://webservice_proxy_routed/hello}sayHello". So, obviously the mapping work
done during initialization is busted in that it won't support more than one. In fact,
looking at the deployment INFO being logged again, you will see the set of
"[SOAPProxy] mapped abc [...] to xyz [...]" mappings twice, but both sets for
GOODBYE. Nothing for HELLO.
I also noticed that the new JBossWSDLReader.java (which is used by SOAPProxy, among other
soap services), is doing serveral System.out.println's. For example,
"17:59:43,631 INFO [STDOUT] Retrieving document at...". These should be using
Log4j.
was:
Each of the webservice_proxy_* quickstarts are broken in some way.
webservice_proxy_basic, webservice_proxy_security and webservice_proxy_versioning all have
problem with their WSDL contracts being empty from the http//localhost:8080/contract/ web
application. Light debugging showed that the reason for this is that
ContractProviderLifecycleResource, while having it's map being propertly populated
with the appropriate lifecycle resource (deployment) ID + ContractProvider instance at
deployment, is returning null when the HttpGatewayServlet attempts to get at it's
appropriate ContractProvider. The reason is that during the thread of execution behind
the HttpGatewayServlet, when calling ContractProviderLifecycleResource.buildKey(svc_cat,
svc_name), LifecycleResourceManager.getSingleton().getIdentity() is returning DEFAULT-ID
(or whatever it's called) instead of the actual deployment ID. This *USED* to work,
so I don't know what changed environment-wise. webservice_proxy_routed doesn't
provide a contract (no HTTP endpoints), so it's N/A to that quickstart.
webservice_proxy_routed has a different problem. It appears the work done in JBESB-3372
("Move SOAP services away from JBossWS-Native implementation") has a bug when
using JBossWS-Native. I thought the purpose was that both the Native and CXF stacks
should work. If only the CXF stack should work, we shouldn't release ESB .org with
Native. Anyway, after lightly looking at the code changes, it appears that there is a
problem with the mappings being done. Specifically the same QName for Operation/Binding
is being reused everywhere, even if there is more than one. When you run the quickstart
with "ant saygoodbye", it work. When you run the quickstart with "ant
sayhello" it breaks. This is because the goodbye QName is what was used. For
example, "{http://webservice_proxy_routed/goodbye}GoodbyeBinding" and
"{http://webservice_proxy_routed/goodbye}sayGoodbye". This is fine for
"ant rungoodbye", but when you run "ant runhello" you get, "ERROR
[SOAPFaultHelperJAXWS] SOAP request exception
org.jboss.ws.core.CommonSOAPFaultException: Endpoint
{http://webservice_proxy_routed/goodbye}GoodbyePort does not contain operation meta data
for: {http://webservice_proxy_routed/hello}sayHello". So, obviously the mapping work
done during initialization is busted in that it won't support more than one. In fact,
looking at the deployment INFO being logged again, you will see the set of
"[SOAPProxy] mapped abc [...] to xyz [...]" mappings twice, but both sets for
GOODBYE. Nothing for HELLO.
All webservice_proxy_* quickstarts are broken
---------------------------------------------
Key: JBESB-3412
URL: https://jira.jboss.org/browse/JBESB-3412
Project: JBoss ESB
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Examples, Web Services
Environment: JDK 1.5 + AS 4.2.3 and JDK 1.6 + AS 5.1.0
Reporter: David Ward
Priority: Blocker
Fix For: 4.9
Attachments: webservice_proxy_routed.log
Each of the webservice_proxy_* quickstarts are broken in some way.
webservice_proxy_basic, webservice_proxy_security and webservice_proxy_versioning all
have problem with their WSDL contracts being empty from the http//localhost:8080/contract/
web application. Light debugging showed that the reason for this is that
ContractProviderLifecycleResource, while having it's map being propertly populated
with the appropriate lifecycle resource (deployment) ID + ContractProvider instance at
deployment, is returning null when the HttpGatewayServlet attempts to get at it's
appropriate ContractProvider. The reason is that during the thread of execution behind
the HttpGatewayServlet, when calling ContractProviderLifecycleResource.buildKey(svc_cat,
svc_name), LifecycleResourceManager.getSingleton().getIdentity() is returning DEFAULT-ID
(or whatever it's called) instead of the actual deployment ID. This *USED* to work,
so I don't know what changed environment-wise. webservice_proxy_routed doesn't
provide a contract (no HTTP endpoints), so it's N/A to that quickstart.
webservice_proxy_routed has a different problem. It appears the work done in JBESB-3372
("Move SOAP services away from JBossWS-Native implementation") has a bug when
using JBossWS-Native. I thought the purpose was that both the Native and CXF stacks
should work. If only the CXF stack should work, we shouldn't release ESB .org with
Native. Anyway, after lightly looking at the code changes, it appears that there is a
problem with the mappings being done. Specifically the same QName for Operation/Binding
is being reused everywhere, even if there is more than one. When you run the quickstart
with "ant saygoodbye", it work. When you run the quickstart with "ant
sayhello" it breaks. This is because the goodbye QName is what was used. For
example, "{http://webservice_proxy_routed/goodbye}GoodbyeBinding" and
"{http://webservice_proxy_routed/goodbye}sayGoodbye". This is fine for
"ant rungoodbye", but when you run "ant runhello" you get, "ERROR
[SOAPFaultHelperJAXWS] SOAP request exception
org.jboss.ws.core.CommonSOAPFaultException: Endpoint
{http://webservice_proxy_routed/goodbye}GoodbyePort does not contain operation meta data
for: {http://webservice_proxy_routed/hello}sayHello". So, obviously the mapping work
done during initialization is busted in that it won't support more than one. In fact,
looking at the deployment INFO being logged again, you will see the set of
"[SOAPProxy] mapped abc [...] to xyz [...]" mappings twice, but both sets for
GOODBYE. Nothing for HELLO.
I also noticed that the new JBossWSDLReader.java (which is used by SOAPProxy, among other
soap services), is doing serveral System.out.println's. For example,
"17:59:43,631 INFO [STDOUT] Retrieving document at...". These should be using
Log4j.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:40 a.m.
New subject: [JBoss JIRA] Assigned: (JBESB-3412) All webservice_proxy_* quickstarts are broken
[
https://jira.jboss.org/browse/JBESB-3412?page=com.atlassian.jira.plugin.s...
]
Magesh Kumar B reassigned JBESB-3412:
-------------------------------------
Assignee: Magesh Kumar B
All webservice_proxy_* quickstarts are broken
---------------------------------------------
Key: JBESB-3412
URL: https://jira.jboss.org/browse/JBESB-3412
Project: JBoss ESB
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Examples, Web Services
Environment: JDK 1.5 + AS 4.2.3 and JDK 1.6 + AS 5.1.0
Reporter: David Ward
Assignee: Magesh Kumar B
Priority: Blocker
Fix For: 4.9
Attachments: webservice_proxy_routed.log
Each of the webservice_proxy_* quickstarts are broken in some way.
webservice_proxy_basic, webservice_proxy_security and webservice_proxy_versioning all
have problem with their WSDL contracts being empty from the http//localhost:8080/contract/
web application. Light debugging showed that the reason for this is that
ContractProviderLifecycleResource, while having it's map being propertly populated
with the appropriate lifecycle resource (deployment) ID + ContractProvider instance at
deployment, is returning null when the HttpGatewayServlet attempts to get at it's
appropriate ContractProvider. The reason is that during the thread of execution behind
the HttpGatewayServlet, when calling ContractProviderLifecycleResource.buildKey(svc_cat,
svc_name), LifecycleResourceManager.getSingleton().getIdentity() is returning DEFAULT-ID
(or whatever it's called) instead of the actual deployment ID. This *USED* to work,
so I don't know what changed environment-wise. webservice_proxy_routed doesn't
provide a contract (no HTTP endpoints), so it's N/A to that quickstart.
webservice_proxy_routed has a different problem. It appears the work done in JBESB-3372
("Move SOAP services away from JBossWS-Native implementation") has a bug when
using JBossWS-Native. I thought the purpose was that both the Native and CXF stacks
should work. If only the CXF stack should work, we shouldn't release ESB .org with
Native. Anyway, after lightly looking at the code changes, it appears that there is a
problem with the mappings being done. Specifically the same QName for Operation/Binding
is being reused everywhere, even if there is more than one. When you run the quickstart
with "ant saygoodbye", it work. When you run the quickstart with "ant
sayhello" it breaks. This is because the goodbye QName is what was used. For
example, "{http://webservice_proxy_routed/goodbye}GoodbyeBinding" and
"{http://webservice_proxy_routed/goodbye}sayGoodbye". This is fine for
"ant rungoodbye", but when you run "ant runhello" you get, "ERROR
[SOAPFaultHelperJAXWS] SOAP request exception
org.jboss.ws.core.CommonSOAPFaultException: Endpoint
{http://webservice_proxy_routed/goodbye}GoodbyePort does not contain operation meta data
for: {http://webservice_proxy_routed/hello}sayHello". So, obviously the mapping work
done during initialization is busted in that it won't support more than one. In fact,
looking at the deployment INFO being logged again, you will see the set of
"[SOAPProxy] mapped abc [...] to xyz [...]" mappings twice, but both sets for
GOODBYE. Nothing for HELLO.
I also noticed that the new JBossWSDLReader.java (which is used by SOAPProxy, among other
soap services), is doing serveral System.out.println's. For example,
"17:59:43,631 INFO [STDOUT] Retrieving document at...". These should be using
Log4j.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:18 a.m.
New subject: [JBoss JIRA] Commented: (JBESB-3412) All webservice_proxy_* quickstarts are broken
[
https://jira.jboss.org/browse/JBESB-3412?page=com.atlassian.jira.plugin.s...
]
Kevin Conner commented on JBESB-3412:
-------------------------------------
Can we please keep one issue per JIRA
All webservice_proxy_* quickstarts are broken
---------------------------------------------
Key: JBESB-3412
URL: https://jira.jboss.org/browse/JBESB-3412
Project: JBoss ESB
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Examples, Web Services
Environment: JDK 1.5 + AS 4.2.3 and JDK 1.6 + AS 5.1.0
Reporter: David Ward
Assignee: Magesh Kumar B
Priority: Blocker
Fix For: 4.9
Attachments: webservice_proxy_routed.log
Each of the webservice_proxy_* quickstarts are broken in some way.
webservice_proxy_basic, webservice_proxy_security and webservice_proxy_versioning all
have problem with their WSDL contracts being empty from the http//localhost:8080/contract/
web application. Light debugging showed that the reason for this is that
ContractProviderLifecycleResource, while having it's map being propertly populated
with the appropriate lifecycle resource (deployment) ID + ContractProvider instance at
deployment, is returning null when the HttpGatewayServlet attempts to get at it's
appropriate ContractProvider. The reason is that during the thread of execution behind
the HttpGatewayServlet, when calling ContractProviderLifecycleResource.buildKey(svc_cat,
svc_name), LifecycleResourceManager.getSingleton().getIdentity() is returning DEFAULT-ID
(or whatever it's called) instead of the actual deployment ID. This *USED* to work,
so I don't know what changed environment-wise. webservice_proxy_routed doesn't
provide a contract (no HTTP endpoints), so it's N/A to that quickstart.
webservice_proxy_routed has a different problem. It appears the work done in JBESB-3372
("Move SOAP services away from JBossWS-Native implementation") has a bug when
using JBossWS-Native. I thought the purpose was that both the Native and CXF stacks
should work. If only the CXF stack should work, we shouldn't release ESB .org with
Native. Anyway, after lightly looking at the code changes, it appears that there is a
problem with the mappings being done. Specifically the same QName for Operation/Binding
is being reused everywhere, even if there is more than one. When you run the quickstart
with "ant saygoodbye", it work. When you run the quickstart with "ant
sayhello" it breaks. This is because the goodbye QName is what was used. For
example, "{http://webservice_proxy_routed/goodbye}GoodbyeBinding" and
"{http://webservice_proxy_routed/goodbye}sayGoodbye". This is fine for
"ant rungoodbye", but when you run "ant runhello" you get, "ERROR
[SOAPFaultHelperJAXWS] SOAP request exception
org.jboss.ws.core.CommonSOAPFaultException: Endpoint
{http://webservice_proxy_routed/goodbye}GoodbyePort does not contain operation meta data
for: {http://webservice_proxy_routed/hello}sayHello". So, obviously the mapping work
done during initialization is busted in that it won't support more than one. In fact,
looking at the deployment INFO being logged again, you will see the set of
"[SOAPProxy] mapped abc [...] to xyz [...]" mappings twice, but both sets for
GOODBYE. Nothing for HELLO.
I also noticed that the new JBossWSDLReader.java (which is used by SOAPProxy, among other
soap services), is doing serveral System.out.println's. For example,
"17:59:43,631 INFO [STDOUT] Retrieving document at...". These should be using
Log4j.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:20 a.m.
New subject: [JBoss JIRA] Commented: (JBESB-3412) All webservice_proxy_* quickstarts are broken
[
https://jira.jboss.org/browse/JBESB-3412?page=com.atlassian.jira.plugin.s...
]
Kevin Conner commented on JBESB-3412:
-------------------------------------
First issue, classloader. If it is returning DEFAULT_ID then it is picking up a
classloader which is not associated with an ESB deployment.
Second issue, yes they should both work so that would be a bug.
Third issue, yes there should be no System.printlns.
All webservice_proxy_* quickstarts are broken
---------------------------------------------
Key: JBESB-3412
URL: https://jira.jboss.org/browse/JBESB-3412
Project: JBoss ESB
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Examples, Web Services
Environment: JDK 1.5 + AS 4.2.3 and JDK 1.6 + AS 5.1.0
Reporter: David Ward
Assignee: Magesh Kumar B
Priority: Blocker
Fix For: 4.9
Attachments: webservice_proxy_routed.log
Each of the webservice_proxy_* quickstarts are broken in some way.
webservice_proxy_basic, webservice_proxy_security and webservice_proxy_versioning all
have problem with their WSDL contracts being empty from the http//localhost:8080/contract/
web application. Light debugging showed that the reason for this is that
ContractProviderLifecycleResource, while having it's map being propertly populated
with the appropriate lifecycle resource (deployment) ID + ContractProvider instance at
deployment, is returning null when the HttpGatewayServlet attempts to get at it's
appropriate ContractProvider. The reason is that during the thread of execution behind
the HttpGatewayServlet, when calling ContractProviderLifecycleResource.buildKey(svc_cat,
svc_name), LifecycleResourceManager.getSingleton().getIdentity() is returning DEFAULT-ID
(or whatever it's called) instead of the actual deployment ID. This *USED* to work,
so I don't know what changed environment-wise. webservice_proxy_routed doesn't
provide a contract (no HTTP endpoints), so it's N/A to that quickstart.
webservice_proxy_routed has a different problem. It appears the work done in JBESB-3372
("Move SOAP services away from JBossWS-Native implementation") has a bug when
using JBossWS-Native. I thought the purpose was that both the Native and CXF stacks
should work. If only the CXF stack should work, we shouldn't release ESB .org with
Native. Anyway, after lightly looking at the code changes, it appears that there is a
problem with the mappings being done. Specifically the same QName for Operation/Binding
is being reused everywhere, even if there is more than one. When you run the quickstart
with "ant saygoodbye", it work. When you run the quickstart with "ant
sayhello" it breaks. This is because the goodbye QName is what was used. For
example, "{http://webservice_proxy_routed/goodbye}GoodbyeBinding" and
"{http://webservice_proxy_routed/goodbye}sayGoodbye". This is fine for
"ant rungoodbye", but when you run "ant runhello" you get, "ERROR
[SOAPFaultHelperJAXWS] SOAP request exception
org.jboss.ws.core.CommonSOAPFaultException: Endpoint
{http://webservice_proxy_routed/goodbye}GoodbyePort does not contain operation meta data
for: {http://webservice_proxy_routed/hello}sayHello". So, obviously the mapping work
done during initialization is busted in that it won't support more than one. In fact,
looking at the deployment INFO being logged again, you will see the set of
"[SOAPProxy] mapped abc [...] to xyz [...]" mappings twice, but both sets for
GOODBYE. Nothing for HELLO.
I also noticed that the new JBossWSDLReader.java (which is used by SOAPProxy, among other
soap services), is doing serveral System.out.println's. For example,
"17:59:43,631 INFO [STDOUT] Retrieving document at...". These should be using
Log4j.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:07 a.m.
New subject: [JBoss JIRA] Updated: (JBESB-3412) webservice_proxy_* WSDL retrieval not associated with correct classloader
[
https://jira.jboss.org/browse/JBESB-3412?page=com.atlassian.jira.plugin.s...
]
Kevin Conner updated JBESB-3412:
--------------------------------
Summary: webservice_proxy_* WSDL retrieval not associated with correct classloader
(was: All webservice_proxy_* quickstarts are broken)
webservice_proxy_* WSDL retrieval not associated with correct
classloader
-------------------------------------------------------------------------
Key: JBESB-3412
URL: https://jira.jboss.org/browse/JBESB-3412
Project: JBoss ESB
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Examples, Web Services
Environment: JDK 1.5 + AS 4.2.3 and JDK 1.6 + AS 5.1.0
Reporter: David Ward
Assignee: Magesh Kumar B
Priority: Blocker
Fix For: 4.9
Attachments: webservice_proxy_routed.log
Each of the webservice_proxy_* quickstarts are broken in some way.
webservice_proxy_basic, webservice_proxy_security and webservice_proxy_versioning all
have problem with their WSDL contracts being empty from the http//localhost:8080/contract/
web application. Light debugging showed that the reason for this is that
ContractProviderLifecycleResource, while having it's map being propertly populated
with the appropriate lifecycle resource (deployment) ID + ContractProvider instance at
deployment, is returning null when the HttpGatewayServlet attempts to get at it's
appropriate ContractProvider. The reason is that during the thread of execution behind
the HttpGatewayServlet, when calling ContractProviderLifecycleResource.buildKey(svc_cat,
svc_name), LifecycleResourceManager.getSingleton().getIdentity() is returning DEFAULT-ID
(or whatever it's called) instead of the actual deployment ID. This *USED* to work,
so I don't know what changed environment-wise. webservice_proxy_routed doesn't
provide a contract (no HTTP endpoints), so it's N/A to that quickstart.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:07 a.m.
New subject: [JBoss JIRA] Updated: (JBESB-3412) All webservice_proxy_* quickstarts are broken
[
https://jira.jboss.org/browse/JBESB-3412?page=com.atlassian.jira.plugin.s...
]
Kevin Conner updated JBESB-3412:
--------------------------------
Description:
Each of the webservice_proxy_* quickstarts are broken in some way.
webservice_proxy_basic, webservice_proxy_security and webservice_proxy_versioning all have
problem with their WSDL contracts being empty from the http//localhost:8080/contract/ web
application. Light debugging showed that the reason for this is that
ContractProviderLifecycleResource, while having it's map being propertly populated
with the appropriate lifecycle resource (deployment) ID + ContractProvider instance at
deployment, is returning null when the HttpGatewayServlet attempts to get at it's
appropriate ContractProvider. The reason is that during the thread of execution behind
the HttpGatewayServlet, when calling ContractProviderLifecycleResource.buildKey(svc_cat,
svc_name), LifecycleResourceManager.getSingleton().getIdentity() is returning DEFAULT-ID
(or whatever it's called) instead of the actual deployment ID. This *USED* to work,
so I don't know what changed environment-wise. webservice_proxy_routed doesn't
provide a contract (no HTTP endpoints), so it's N/A to that quickstart.
was:
Each of the webservice_proxy_* quickstarts are broken in some way.
webservice_proxy_basic, webservice_proxy_security and webservice_proxy_versioning all have
problem with their WSDL contracts being empty from the http//localhost:8080/contract/ web
application. Light debugging showed that the reason for this is that
ContractProviderLifecycleResource, while having it's map being propertly populated
with the appropriate lifecycle resource (deployment) ID + ContractProvider instance at
deployment, is returning null when the HttpGatewayServlet attempts to get at it's
appropriate ContractProvider. The reason is that during the thread of execution behind
the HttpGatewayServlet, when calling ContractProviderLifecycleResource.buildKey(svc_cat,
svc_name), LifecycleResourceManager.getSingleton().getIdentity() is returning DEFAULT-ID
(or whatever it's called) instead of the actual deployment ID. This *USED* to work,
so I don't know what changed environment-wise. webservice_proxy_routed doesn't
provide a contract (no HTTP endpoints), so it's N/A to that quickstart.
webservice_proxy_routed has a different problem. It appears the work done in JBESB-3372
("Move SOAP services away from JBossWS-Native implementation") has a bug when
using JBossWS-Native. I thought the purpose was that both the Native and CXF stacks
should work. If only the CXF stack should work, we shouldn't release ESB .org with
Native. Anyway, after lightly looking at the code changes, it appears that there is a
problem with the mappings being done. Specifically the same QName for Operation/Binding
is being reused everywhere, even if there is more than one. When you run the quickstart
with "ant saygoodbye", it work. When you run the quickstart with "ant
sayhello" it breaks. This is because the goodbye QName is what was used. For
example, "{http://webservice_proxy_routed/goodbye}GoodbyeBinding" and
"{http://webservice_proxy_routed/goodbye}sayGoodbye". This is fine for
"ant rungoodbye", but when you run "ant runhello" you get, "ERROR
[SOAPFaultHelperJAXWS] SOAP request exception
org.jboss.ws.core.CommonSOAPFaultException: Endpoint
{http://webservice_proxy_routed/goodbye}GoodbyePort does not contain operation meta data
for: {http://webservice_proxy_routed/hello}sayHello". So, obviously the mapping work
done during initialization is busted in that it won't support more than one. In fact,
looking at the deployment INFO being logged again, you will see the set of
"[SOAPProxy] mapped abc [...] to xyz [...]" mappings twice, but both sets for
GOODBYE. Nothing for HELLO.
I also noticed that the new JBossWSDLReader.java (which is used by SOAPProxy, among other
soap services), is doing serveral System.out.println's. For example,
"17:59:43,631 INFO [STDOUT] Retrieving document at...". These should be using
Log4j.
Second issue handled by JBESB-3372, third issue by JBESB-3413
All webservice_proxy_* quickstarts are broken
---------------------------------------------
Key: JBESB-3412
URL: https://jira.jboss.org/browse/JBESB-3412
Project: JBoss ESB
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Examples, Web Services
Environment: JDK 1.5 + AS 4.2.3 and JDK 1.6 + AS 5.1.0
Reporter: David Ward
Assignee: Magesh Kumar B
Priority: Blocker
Fix For: 4.9
Attachments: webservice_proxy_routed.log
Each of the webservice_proxy_* quickstarts are broken in some way.
webservice_proxy_basic, webservice_proxy_security and webservice_proxy_versioning all
have problem with their WSDL contracts being empty from the http//localhost:8080/contract/
web application. Light debugging showed that the reason for this is that
ContractProviderLifecycleResource, while having it's map being propertly populated
with the appropriate lifecycle resource (deployment) ID + ContractProvider instance at
deployment, is returning null when the HttpGatewayServlet attempts to get at it's
appropriate ContractProvider. The reason is that during the thread of execution behind
the HttpGatewayServlet, when calling ContractProviderLifecycleResource.buildKey(svc_cat,
svc_name), LifecycleResourceManager.getSingleton().getIdentity() is returning DEFAULT-ID
(or whatever it's called) instead of the actual deployment ID. This *USED* to work,
so I don't know what changed environment-wise. webservice_proxy_routed doesn't
provide a contract (no HTTP endpoints), so it's N/A to that quickstart.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:09 a.m.
New subject: [JBoss JIRA] Updated: (JBESB-3412) webservice_proxy_* WSDL retrieval not associated with correct classloader
[
https://jira.jboss.org/browse/JBESB-3412?page=com.atlassian.jira.plugin.s...
]
Kevin Conner updated JBESB-3412:
--------------------------------
Description:
webservice_proxy_basic, webservice_proxy_security and webservice_proxy_versioning all have
problem with their WSDL contracts being empty from the http//localhost:8080/contract/ web
application. Light debugging showed that the reason for this is that
ContractProviderLifecycleResource, while having it's map being propertly populated
with the appropriate lifecycle resource (deployment) ID + ContractProvider instance at
deployment, is returning null when the HttpGatewayServlet attempts to get at it's
appropriate ContractProvider. The reason is that during the thread of execution behind
the HttpGatewayServlet, when calling ContractProviderLifecycleResource.buildKey(svc_cat,
svc_name), LifecycleResourceManager.getSingleton().getIdentity() is returning DEFAULT-ID
(or whatever it's called) instead of the actual deployment ID. This *USED* to work,
so I don't know what changed environment-wise. webservice_proxy_routed doesn't
provide a contract (no HTTP endpoints), so it's N/A to that quickstart.
was:
Each of the webservice_proxy_* quickstarts are broken in some way.
webservice_proxy_basic, webservice_proxy_security and webservice_proxy_versioning all have
problem with their WSDL contracts being empty from the http//localhost:8080/contract/ web
application. Light debugging showed that the reason for this is that
ContractProviderLifecycleResource, while having it's map being propertly populated
with the appropriate lifecycle resource (deployment) ID + ContractProvider instance at
deployment, is returning null when the HttpGatewayServlet attempts to get at it's
appropriate ContractProvider. The reason is that during the thread of execution behind
the HttpGatewayServlet, when calling ContractProviderLifecycleResource.buildKey(svc_cat,
svc_name), LifecycleResourceManager.getSingleton().getIdentity() is returning DEFAULT-ID
(or whatever it's called) instead of the actual deployment ID. This *USED* to work,
so I don't know what changed environment-wise. webservice_proxy_routed doesn't
provide a contract (no HTTP endpoints), so it's N/A to that quickstart.
webservice_proxy_* WSDL retrieval not associated with correct
classloader
-------------------------------------------------------------------------
Key: JBESB-3412
URL: https://jira.jboss.org/browse/JBESB-3412
Project: JBoss ESB
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Examples, Web Services
Environment: JDK 1.5 + AS 4.2.3 and JDK 1.6 + AS 5.1.0
Reporter: David Ward
Assignee: Magesh Kumar B
Priority: Blocker
Fix For: 4.9
Attachments: webservice_proxy_routed.log
webservice_proxy_basic, webservice_proxy_security and webservice_proxy_versioning all
have problem with their WSDL contracts being empty from the http//localhost:8080/contract/
web application. Light debugging showed that the reason for this is that
ContractProviderLifecycleResource, while having it's map being propertly populated
with the appropriate lifecycle resource (deployment) ID + ContractProvider instance at
deployment, is returning null when the HttpGatewayServlet attempts to get at it's
appropriate ContractProvider. The reason is that during the thread of execution behind
the HttpGatewayServlet, when calling ContractProviderLifecycleResource.buildKey(svc_cat,
svc_name), LifecycleResourceManager.getSingleton().getIdentity() is returning DEFAULT-ID
(or whatever it's called) instead of the actual deployment ID. This *USED* to work,
so I don't know what changed environment-wise. webservice_proxy_routed doesn't
provide a contract (no HTTP endpoints), so it's N/A to that quickstart.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:11 a.m.
New subject: [JBoss JIRA] Assigned: (JBESB-3412) webservice_proxy_* WSDL retrieval not associated with correct classloader
[
https://jira.jboss.org/browse/JBESB-3412?page=com.atlassian.jira.plugin.s...
]
Kevin Conner reassigned JBESB-3412:
-----------------------------------
Assignee: Kevin Conner (was: Magesh Kumar B)
webservice_proxy_* WSDL retrieval not associated with correct
classloader
-------------------------------------------------------------------------
Key: JBESB-3412
URL: https://jira.jboss.org/browse/JBESB-3412
Project: JBoss ESB
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Examples, Web Services
Environment: JDK 1.5 + AS 4.2.3 and JDK 1.6 + AS 5.1.0
Reporter: David Ward
Assignee: Kevin Conner
Priority: Blocker
Fix For: 4.9
Attachments: webservice_proxy_routed.log
webservice_proxy_basic, webservice_proxy_security and webservice_proxy_versioning all
have problem with their WSDL contracts being empty from the http//localhost:8080/contract/
web application. Light debugging showed that the reason for this is that
ContractProviderLifecycleResource, while having it's map being propertly populated
with the appropriate lifecycle resource (deployment) ID + ContractProvider instance at
deployment, is returning null when the HttpGatewayServlet attempts to get at it's
appropriate ContractProvider. The reason is that during the thread of execution behind
the HttpGatewayServlet, when calling ContractProviderLifecycleResource.buildKey(svc_cat,
svc_name), LifecycleResourceManager.getSingleton().getIdentity() is returning DEFAULT-ID
(or whatever it's called) instead of the actual deployment ID. This *USED* to work,
so I don't know what changed environment-wise. webservice_proxy_routed doesn't
provide a contract (no HTTP endpoints), so it's N/A to that quickstart.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:47 a.m.
New subject: [JBoss JIRA] Commented: (JBESB-3412) webservice_proxy_* WSDL retrieval not associated with correct classloader
[
https://jira.jboss.org/browse/JBESB-3412?page=com.atlassian.jira.plugin.s...
]
Kevin Conner commented on JBESB-3412:
-------------------------------------
It looks like the war deployments are now being deployed separately rather than as a
subdeployment of the esb. This is likely to be the reason why it no longer associates
with the esb deployment.
webservice_proxy_* WSDL retrieval not associated with correct
classloader
-------------------------------------------------------------------------
Key: JBESB-3412
URL: https://jira.jboss.org/browse/JBESB-3412
Project: JBoss ESB
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Examples, Web Services
Environment: JDK 1.5 + AS 4.2.3 and JDK 1.6 + AS 5.1.0
Reporter: David Ward
Assignee: Kevin Conner
Priority: Blocker
Fix For: 4.9
Attachments: webservice_proxy_routed.log
webservice_proxy_basic, webservice_proxy_security and webservice_proxy_versioning all
have problem with their WSDL contracts being empty from the http//localhost:8080/contract/
web application. Light debugging showed that the reason for this is that
ContractProviderLifecycleResource, while having it's map being propertly populated
with the appropriate lifecycle resource (deployment) ID + ContractProvider instance at
deployment, is returning null when the HttpGatewayServlet attempts to get at it's
appropriate ContractProvider. The reason is that during the thread of execution behind
the HttpGatewayServlet, when calling ContractProviderLifecycleResource.buildKey(svc_cat,
svc_name), LifecycleResourceManager.getSingleton().getIdentity() is returning DEFAULT-ID
(or whatever it's called) instead of the actual deployment ID. This *USED* to work,
so I don't know what changed environment-wise. webservice_proxy_routed doesn't
provide a contract (no HTTP endpoints), so it's N/A to that quickstart.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:10 p.m.
New subject: [JBoss JIRA] Commented: (JBESB-3412) webservice_proxy_* WSDL retrieval not associated with correct classloader
[
https://jira.jboss.org/browse/JBESB-3412?page=com.atlassian.jira.plugin.s...
]
Kevin Conner commented on JBESB-3412:
-------------------------------------
The code has been changed so that the servlets/webservices obtain the correct classloader
from the LifecycleResourceManager and wrap invocations by setting the correct TCCL.
This is a hack, no question, but fixing this properly would involve a rewrite of that
code. We will address this properly at a later date.
The changes are committed in revision 34470, a proper test will be added tomorrow.
webservice_proxy_* WSDL retrieval not associated with correct
classloader
-------------------------------------------------------------------------
Key: JBESB-3412
URL: https://jira.jboss.org/browse/JBESB-3412
Project: JBoss ESB
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Examples, Web Services
Environment: JDK 1.5 + AS 4.2.3 and JDK 1.6 + AS 5.1.0
Reporter: David Ward
Assignee: Kevin Conner
Priority: Blocker
Fix For: 4.9
Attachments: webservice_proxy_routed.log
webservice_proxy_basic, webservice_proxy_security and webservice_proxy_versioning all
have problem with their WSDL contracts being empty from the http//localhost:8080/contract/
web application. Light debugging showed that the reason for this is that
ContractProviderLifecycleResource, while having it's map being propertly populated
with the appropriate lifecycle resource (deployment) ID + ContractProvider instance at
deployment, is returning null when the HttpGatewayServlet attempts to get at it's
appropriate ContractProvider. The reason is that during the thread of execution behind
the HttpGatewayServlet, when calling ContractProviderLifecycleResource.buildKey(svc_cat,
svc_name), LifecycleResourceManager.getSingleton().getIdentity() is returning DEFAULT-ID
(or whatever it's called) instead of the actual deployment ID. This *USED* to work,
so I don't know what changed environment-wise. webservice_proxy_routed doesn't
provide a contract (no HTTP endpoints), so it's N/A to that quickstart.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:53 p.m.
New subject: [JBoss JIRA] Commented: (JBESB-3412) webservice_proxy_* WSDL retrieval not associated with correct classloader
[
https://jira.jboss.org/browse/JBESB-3412?page=com.atlassian.jira.plugin.s...
]
David Ward commented on JBESB-3412:
-----------------------------------
Kev, I tested this under jdk 5 + as 4.2.3, and jdk 6 + as 5.1.0, going through all the
webservice_proxy_* quickstarts. I also tested it with the JBR http gateway, in addition
to the new HttpGateway. Thanks - I'll close JBESB-3383 now.
webservice_proxy_* WSDL retrieval not associated with correct
classloader
-------------------------------------------------------------------------
Key: JBESB-3412
URL: https://jira.jboss.org/browse/JBESB-3412
Project: JBoss ESB
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Examples, Web Services
Environment: JDK 1.5 + AS 4.2.3 and JDK 1.6 + AS 5.1.0
Reporter: David Ward
Assignee: Kevin Conner
Priority: Blocker
Fix For: 4.9
Attachments: webservice_proxy_routed.log
webservice_proxy_basic, webservice_proxy_security and webservice_proxy_versioning all
have problem with their WSDL contracts being empty from the http//localhost:8080/contract/
web application. Light debugging showed that the reason for this is that
ContractProviderLifecycleResource, while having it's map being propertly populated
with the appropriate lifecycle resource (deployment) ID + ContractProvider instance at
deployment, is returning null when the HttpGatewayServlet attempts to get at it's
appropriate ContractProvider. The reason is that during the thread of execution behind
the HttpGatewayServlet, when calling ContractProviderLifecycleResource.buildKey(svc_cat,
svc_name), LifecycleResourceManager.getSingleton().getIdentity() is returning DEFAULT-ID
(or whatever it's called) instead of the actual deployment ID. This *USED* to work,
so I don't know what changed environment-wise. webservice_proxy_routed doesn't
provide a contract (no HTTP endpoints), so it's N/A to that quickstart.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:04 p.m.
New subject: [JBoss JIRA] Closed: (JBESB-3412) webservice_proxy_* WSDL retrieval not associated with correct classloader
[
https://jira.jboss.org/browse/JBESB-3412?page=com.atlassian.jira.plugin.s...
]
Kevin Conner closed JBESB-3412.
-------------------------------
Resolution: Done
Integration test added in revision 34485.
webservice_proxy_* WSDL retrieval not associated with correct
classloader
-------------------------------------------------------------------------
Key: JBESB-3412
URL: https://jira.jboss.org/browse/JBESB-3412
Project: JBoss ESB
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Examples, Web Services
Environment: JDK 1.5 + AS 4.2.3 and JDK 1.6 + AS 5.1.0
Reporter: David Ward
Assignee: Kevin Conner
Priority: Blocker
Fix For: 4.9
Attachments: webservice_proxy_routed.log
webservice_proxy_basic, webservice_proxy_security and webservice_proxy_versioning all
have problem with their WSDL contracts being empty from the http//localhost:8080/contract/
web application. Light debugging showed that the reason for this is that
ContractProviderLifecycleResource, while having it's map being propertly populated
with the appropriate lifecycle resource (deployment) ID + ContractProvider instance at
deployment, is returning null when the HttpGatewayServlet attempts to get at it's
appropriate ContractProvider. The reason is that during the thread of execution behind
the HttpGatewayServlet, when calling ContractProviderLifecycleResource.buildKey(svc_cat,
svc_name), LifecycleResourceManager.getSingleton().getIdentity() is returning DEFAULT-ID
(or whatever it's called) instead of the actual deployment ID. This *USED* to work,
so I don't know what changed environment-wise. webservice_proxy_routed doesn't
provide a contract (no HTTP endpoints), so it's N/A to that quickstart.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:52 a.m.
New subject: [JBoss JIRA] Reopened: (JBESB-3412) webservice_proxy_* WSDL retrieval not associated with correct classloader
[
https://jira.jboss.org/browse/JBESB-3412?page=com.atlassian.jira.plugin.s...
]
Kevin Conner reopened JBESB-3412:
---------------------------------
Sorry guys, I have broken the build for jdk 1.5 runs.
Am handling it now.
webservice_proxy_* WSDL retrieval not associated with correct
classloader
-------------------------------------------------------------------------
Key: JBESB-3412
URL: https://jira.jboss.org/browse/JBESB-3412
Project: JBoss ESB
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Examples, Web Services
Environment: JDK 1.5 + AS 4.2.3 and JDK 1.6 + AS 5.1.0
Reporter: David Ward
Assignee: Kevin Conner
Priority: Blocker
Fix For: 4.9
Attachments: webservice_proxy_routed.log
webservice_proxy_basic, webservice_proxy_security and webservice_proxy_versioning all
have problem with their WSDL contracts being empty from the http//localhost:8080/contract/
web application. Light debugging showed that the reason for this is that
ContractProviderLifecycleResource, while having it's map being propertly populated
with the appropriate lifecycle resource (deployment) ID + ContractProvider instance at
deployment, is returning null when the HttpGatewayServlet attempts to get at it's
appropriate ContractProvider. The reason is that during the thread of execution behind
the HttpGatewayServlet, when calling ContractProviderLifecycleResource.buildKey(svc_cat,
svc_name), LifecycleResourceManager.getSingleton().getIdentity() is returning DEFAULT-ID
(or whatever it's called) instead of the actual deployment ID. This *USED* to work,
so I don't know what changed environment-wise. webservice_proxy_routed doesn't
provide a contract (no HTTP endpoints), so it's N/A to that quickstart.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:42 a.m.
New subject: [JBoss JIRA] Closed: (JBESB-3412) webservice_proxy_* WSDL retrieval not associated with correct classloader
[
https://jira.jboss.org/browse/JBESB-3412?page=com.atlassian.jira.plugin.s...
]
Kevin Conner closed JBESB-3412.
-------------------------------
Resolution: Done
jbossws-native-jaxws.jar added to base-cp.xml as5 classpath in revision 34507.
webservice_proxy_* WSDL retrieval not associated with correct
classloader
-------------------------------------------------------------------------
Key: JBESB-3412
URL: https://jira.jboss.org/browse/JBESB-3412
Project: JBoss ESB
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Examples, Web Services
Environment: JDK 1.5 + AS 4.2.3 and JDK 1.6 + AS 5.1.0
Reporter: David Ward
Assignee: Kevin Conner
Priority: Blocker
Fix For: 4.9
Attachments: webservice_proxy_routed.log
webservice_proxy_basic, webservice_proxy_security and webservice_proxy_versioning all
have problem with their WSDL contracts being empty from the http//localhost:8080/contract/
web application. Light debugging showed that the reason for this is that
ContractProviderLifecycleResource, while having it's map being propertly populated
with the appropriate lifecycle resource (deployment) ID + ContractProvider instance at
deployment, is returning null when the HttpGatewayServlet attempts to get at it's
appropriate ContractProvider. The reason is that during the thread of execution behind
the HttpGatewayServlet, when calling ContractProviderLifecycleResource.buildKey(svc_cat,
svc_name), LifecycleResourceManager.getSingleton().getIdentity() is returning DEFAULT-ID
(or whatever it's called) instead of the actual deployment ID. This *USED* to work,
so I don't know what changed environment-wise. webservice_proxy_routed doesn't
provide a contract (no HTTP endpoints), so it's N/A to that quickstart.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5232
days inactive
5237
days old
16 comments
3 participants
participants (3)
-
David Ward (JIRA) -
Kevin Conner (JIRA)
-
Magesh Kumar B (JIRA)