February 2009 - jbossws-dev - Jboss List Archives

[Design of JBoss Web Services] - Re: Dynamic Endpoint Deployment

by kabir.khan＠jboss.com

To be clear I can work around this with my AOP release. So this is not blocking me View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209558#4209558 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209558

17 years, 1 month

1
0
0 / 0

[Design of JBoss Web Services] - Re: Dynamic Endpoint Deployment

by richard.opalka＠jboss.com

"kabir.khan(a)jboss.com" wrote : | If that doesn't work I think you need to create a ClassLoadingMetaData from the Module, and put that into the deployment as an attachment. We don't have the Module reference available :( As I said above, we're doing all the magic from servlet code (we're not in deployers processing chain when creating that "minimalistic Deployment") :( View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209556#4209556 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209556

17 years, 1 month

1
0
0 / 0

[Design of JBoss Web Services] - Re: Dynamic Endpoint Deployment

by kabir.khan＠jboss.com

This is what causes the error in https://jira.jboss.org/jira/browse/JBAS-6489. I am testing a fix in AOP to make it more resistant to things like this, but I think this root cause needs addressing. I still need to do an AOP 2.0.1.GA which I am aiming to do today. As far as I can tell the work needed for the issue on this thread is in the AS source in org.jboss.wsf.container.jboss50.transport.DynamicEndpointDeploymentAspect. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209555#4209555 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209555

17 years, 1 month

1
0
0 / 0

[Design of JBoss Web Services] - Re: Dynamic Endpoint Deployment

by dimitris＠jboss.org

Guys, I need to understand if any of this work should hold the AS 5.0.1 release and what exactly would have to be changed. Any pending component updates? Thanks. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209543#4209543 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209543

17 years, 1 month

1
0
0 / 0

[Design of JBoss Web Services] - Re: Dynamic Endpoint Deployment

by kabir.khan＠jboss.com

"richard.opalka(a)jboss.com" wrote : | anonymous wrote : | | Somehow the new deployment created internally needs to either include the original Module, | | | I don't know how to achieve that because web service endpoint is published from servlet and we do not have access to DeploymentUnit from it :( | If you have the deployment's ClassLoader, you can obtain the Module by calling org.jboss.classloading.spi.dependency.ClassLoading.getModuleForClassLoader() This method exists in the version of jboss-cl that exists in AS Branch_5_0. I am not sure if adding the Module as an attachment to the created deployment will have any effect since it looks like a Module is always created by AbstractClassLoaderDescribeDeployer/VFSClassLoaderDescribeDeployer, but you can try. If that doesn't work I think you need to create a ClassLoadingMetaData from the Module, and put that into the deployment as an attachment. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209542#4209542 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209542

17 years, 1 month

1
0
0 / 0

[Design of JBoss Web Services] - Re: Dynamic Endpoint Deployment

by richard.opalka＠jboss.com

In this thread we're talking about the following part of the stack trace: MainDeployerImpl.deploy(Deployment...) line: 445 DynamicEndpointDeploymentAspect.create(Deployment) line: 88 DeploymentAspectManagerImpl.deploy(Deployment) line: 115 DeploymentAspectHttpServer.publish(HttpContext, Endpoint) line: 91 EndpointImpl.publish(Object) line: 172 EndpointServlet.init(ServletConfig) line: 70 StandardWrapper.loadServlet() line: 1048 StandardWrapper.load() line: 950 StandardContext.loadOnStartup(Container[]) line: 4122 StandardContext.start() line: 4421 TomcatDeployment.performDeployInternal(WebApplication, String, String) line: 315 TomcatDeployment.performDeploy(WebApplication, String) line: 147 TomcatDeployment(AbstractWarDeployment).start(DeploymentUnit, JBossWebMetaData) line: 461 WebModule.startModule() line: 118 WebModule.start() line: 97 anonymous wrote : | Hot-deploying the war seems to go through the deployer chain twice. Once, when it goes through usual hot-deployment (See Stack1 below), then it does something in the tomcat/service-layer, I guess to deploy the WS endpoint (See Stack2 below). | Correct, it goes through deployers chain twice. This is evident from the stack trace above ;) anonymous wrote : | Now the problem is that the first time it deploys this, it correctly includes a Module attachment with the deploymentunit which links the classloader to a scoped classloading domain called "vfszip:/Users/kabir/sourcecontrol/jbossas/Branch_5_0/testsuite/output/lib/jaxws-endpoint-servlet.war" (See variables1 below). Correct because first walk through deployers chain is pure web app deployment (Servlet in war) anonymous wrote : | When it deploys the second time, it incorrectly includes a Module attachment with the deploymentunit linking the classloader to the main/non-scoped classloading domain called DefaultDomain. We do construct "minimal Deployment" needed to pass the deployers chain programatically (because we're calling MainDeployer.deploy() from servlet code). Regarding the classloading issue you're facing it's because our DynamicEndpointDeploymentAspect puts Servlet context classloader to the constructed "minimal Deployment". anonymous wrote : | Somehow the new deployment created internally needs to either include the original Module, | I don't know how to achieve that because web service endpoint is published from servlet and we do not have access to DeploymentUnit from it :( anonymous wrote : or the correct classloading metadata to reuse the name "vfszip:/Users/kabir/sourcecontrol/jbossas/Branch_5_0/testsuite/output/lib/jaxws-endpoint-servlet.war". | How to achieve that if we don't have access to DeploymentUnit? Is it possible to construct it dynamically? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209503#4209503 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209503

17 years, 1 month

1
0
0 / 0

[Design of JBoss Web Services] - Dynamic Endpoint Deployment

by richard.opalka＠jboss.com

Kabir Khan wrote: If you've seen the dev-list discussions yesterday regarding JBAS-6489, I can work around this in AOP, but I have found the cause to be something to do with org.jboss.test.webservice.endpoint.EndpointTestCase. It deploys jaxws-endpoint-servlet.war. Hot-deploying the war seems to go through the deployer chain twice. Once, when it goes through usual hot-deployment (See Stack1 below), then it does something in the tomcat/service-layer, I guess to deploy the WS endpoint (See Stack2 below). Now the problem is that the first time it deploys this, it correctly includes a Module attachment with the deploymentunit which links the classloader to a scoped classloading domain called "vfszip:/Users/kabir/sourcecontrol/jbossas/Branch_5_0/testsuite/output/lib/jaxws-endpoint-servlet.war" (See variables1 below). When it deploys the second time, it incorrectly includes a Module attachment with the deploymentunit linking the classloader to the main/non-scoped classloading domain called DefaultDomain. Somehow the new deployment created internally needs to either include the original Module, or the correct classloading metadata to reuse the name "vfszip:/Users/kabir/sourcecontrol/jbossas/Branch_5_0/testsuite/output/lib/jaxws-endpoint-servlet.war". I think this happens around this point of Stack2: DynamicEndpointDeploymentAspect.create(Deployment) line: 88 DeploymentAspectManagerImpl.deploy(Deployment) line: 115 DeploymentAspectHttpServer.publish(HttpContext, Endpoint) line: 91 Since deployment 2 also passes through the AOPClassLoader deployer and it is getting the wrong information, AOP gets confused about the AOP domains used. Stack1: Daemon System Thread [RMI TCP Connection(10)-127.0.0.1] (Suspended (breakpoint at line 58 in VFSClassLoaderDomainRegistry)) VFSClassLoaderDomainRegistry.initMapsForLoader(ClassLoader, Module, ScopedVFSClassLoaderDomain, ClassLoader) line: 58 AOPClassLoaderInitializer.registerLoaders(AOPClassLoaderScopingPolicyWithRegistry, DeploymentUnit) line: 78 AOPClassLoaderInitializer.initializeForUnit(DeploymentUnit) line: 41 AOPClassLoaderDeployer.internalDeploy(DeploymentUnit) line: 65 AOPClassLoaderDeployer(AbstractRealDeployer).deploy(DeploymentUnit) line: 50 DeployerWrapper.deploy(DeploymentUnit) line: 171 DeployersImpl.doDeploy(Deployer, DeploymentUnit) line: 1439 DeployersImpl.doInstallParentFirst(Deployer, DeploymentContext) line: 1157 DeployersImpl.install(ControllerContext, ControllerState, ControllerState) line: 1098 DeploymentControllerContext(AbstractControllerContext).install(ControllerState, ControllerState) line: 348 AbstractKernelController(AbstractController).install(ControllerContext, ControllerState, ControllerState) line: 1598 AbstractKernelController(AbstractController).incrementState(ControllerContext, boolean) line: 934 AbstractKernelController(AbstractController).resolveContexts(ControllerState, ControllerState, boolean) line: 1062 AbstractKernelController(AbstractController).resolveContexts(boolean) line: 984 AbstractKernelController(AbstractController).change(ControllerContext, ControllerState, boolean) line: 822 AbstractKernelController(AbstractController).change(ControllerContext, ControllerState) line: 553 DeployersImpl.process(List, List) line: 781 MainDeployerImpl.process() line: 572 MainDeployer.deploy(URL) line: 812 MainDeployer.redeploy(URL) line: 587 Stack2: Daemon System Thread [RMI TCP Connection(10)-127.0.0.1] (Suspended (breakpoint at line 58 in VFSClassLoaderDomainRegistry)) VFSClassLoaderDomainRegistry.initMapsForLoader(ClassLoader, Module, ScopedVFSClassLoaderDomain, ClassLoader) line: 58 AOPClassLoaderInitializer.registerLoaders(AOPClassLoaderScopingPolicyWithRegistry, DeploymentUnit) line: 78 AOPClassLoaderInitializer.initializeForUnit(DeploymentUnit) line: 41 AOPClassLoaderDeployer.internalDeploy(DeploymentUnit) line: 65 AOPClassLoaderDeployer(AbstractRealDeployer).deploy(DeploymentUnit) line: 50 DeployerWrapper.deploy(DeploymentUnit) line: 171 DeployersImpl.doDeploy(Deployer, DeploymentUnit) line: 1439 DeployersImpl.doInstallParentFirst(Deployer, DeploymentContext) line: 1157 DeployersImpl.install(ControllerContext, ControllerState, ControllerState) line: 1098 DeploymentControllerContext(AbstractControllerContext).install(ControllerState, ControllerState) line: 348 AbstractKernelController(AbstractController).install(ControllerContext, ControllerState, ControllerState) line: 1598 AbstractKernelController(AbstractController).incrementState(ControllerContext, boolean) line: 934 AbstractKernelController(AbstractController).resolveContexts(ControllerState, ControllerState, boolean) line: 1062 AbstractKernelController(AbstractController).resolveContexts(boolean) line: 984 AbstractKernelController(AbstractController).change(ControllerContext, ControllerState, boolean) line: 822 AbstractKernelController(AbstractController).change(ControllerContext, ControllerState) line: 553 DeployersImpl.process(List, List) line: 781 MainDeployerImpl.deploy(Deployment...) line: 445 DynamicEndpointDeploymentAspect.create(Deployment) line: 88 DeploymentAspectManagerImpl.deploy(Deployment) line: 115 DeploymentAspectHttpServer.publish(HttpContext, Endpoint) line: 91 EndpointImpl.publish(Object) line: 172 EndpointServlet.init(ServletConfig) line: 70 StandardWrapper.loadServlet() line: 1048 StandardWrapper.load() line: 950 StandardContext.loadOnStartup(Container[]) line: 4122 StandardContext.start() line: 4421 TomcatDeployment.performDeployInternal(WebApplication, String, String) line: 315 TomcatDeployment.performDeploy(WebApplication, String) line: 147 TomcatDeployment(AbstractWarDeployment).start(DeploymentUnit, JBossWebMetaData) line: 461 WebModule.startModule() line: 118 WebModule.start() line: 97 NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method] NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39 DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25 Method.invoke(Object, Object...) line: 597 ReflectedDispatcher.invoke(Invocation) line: 157 Invocation.dispatch() line: 96 Invocation.invoke() line: 88 XMBean(AbstractMBeanInvoker).invoke(String, Object[], String[]) line: 264 MBeanServerImpl.invoke(ObjectName, String, Object[], String[]) line: 668 ServiceProxy.invoke(Object, Method, Object[]) line: 206 $Proxy36.start() line: not available StartStopLifecycleAction.installAction(ServiceControllerContext) line: 42 StartStopLifecycleAction.installAction(ControllerContext) line: 37 StartStopLifecycleAction(SimpleControllerContextAction).simpleInstallAction(T) line: 62 StartStopLifecycleAction(AccessControllerContextAction<S,T>).install(ControllerContext) line: 71 ServiceControllerContextActions(AbstractControllerContextActions).install(ControllerContext, ControllerState, ControllerState) line: 51 ServiceControllerContext(AbstractControllerContext).install(ControllerState, ControllerState) line: 348 ServiceControllerContext.install(ControllerState, ControllerState) line: 286 AbstractKernelController(AbstractController).install(ControllerContext, ControllerState, ControllerState) line: 1598 AbstractKernelController(AbstractController).incrementState(ControllerContext, boolean) line: 934 AbstractKernelController(AbstractController).resolveContexts(ControllerState, ControllerState, boolean) line: 1062 AbstractKernelController(AbstractController).resolveContexts(boolean) line: 984 AbstractKernelController(AbstractController).change(ControllerContext, ControllerState, boolean) line: 822 AbstractKernelController(AbstractController).change(ControllerContext, ControllerState) line: 553 ServiceController.doChange(KernelController, ServiceControllerContext, ControllerState, String) line: 688 ServiceController.start(ObjectName) line: 460 ServiceDeployer.start(ServiceContext) line: 163 ServiceDeployer.deploy(DeploymentUnit, ServiceMetaData) line: 99 ServiceDeployer.deploy(DeploymentUnit, Object) line: 46 ServiceDeployer(AbstractSimpleRealDeployer).internalDeploy(DeploymentUnit) line: 62 ServiceDeployer(AbstractRealDeployer).deploy(DeploymentUnit) line: 50 DeployerWrapper.deploy(DeploymentUnit) line: 171 DeployersImpl.doDeploy(Deployer, DeploymentUnit) line: 1439 DeployersImpl.doInstallParentFirst(Deployer, DeploymentContext) line: 1157 DeployersImpl.doInstallParentFirst(Deployer, DeploymentContext) line: 1178 DeployersImpl.install(ControllerContext, ControllerState, ControllerState) line: 1098 DeploymentControllerContext(AbstractControllerContext).install(ControllerState, ControllerState) line: 348 AbstractKernelController(AbstractController).install(ControllerContext, ControllerState, ControllerState) line: 1598 AbstractKernelController(AbstractController).incrementState(ControllerContext, boolean) line: 934 AbstractKernelController(AbstractController).resolveContexts(ControllerState, ControllerState, boolean) line: 1062 AbstractKernelController(AbstractController).resolveContexts(boolean) line: 984 AbstractKernelController(AbstractController).change(ControllerContext, ControllerState, boolean) line: 822 AbstractKernelController(AbstractController).change(ControllerContext, ControllerState) line: 553 DeployersImpl.process(List, List) line: 781 MainDeployerImpl.process() line: 572 MainDeployer.deploy(URL) line: 812 MainDeployer.redeploy(URL) line: 587 Variables1: loader BaseClassLoader (id=641) module VFSDeploymentClassLoaderPolicyModule (id=676) capabilities CopyOnWriteArrayList (id=677) classLoader BaseClassLoader (id=641) classLoadingMetaData ClassLoadingMetaData (id=678) context DeploymentControllerContext (id=637) contextName "vfszip:/Users/kabir/sourcecontrol/jbossas/Branch_5_0/testsuite/output/lib/jaxws-endpoint-servlet.war" (id=666) domain Domain (id=361) classLoading ClassLoading (id=701) modules CopyOnWriteArrayList (id=703) modulesByName ConcurrentHashMap<K,V> (id=704) name "vfszip:/Users/kabir/sourcecontrol/jbossas/Branch_5_0/testsuite/output/lib/jaxws-endpoint-servlet.war" (id=261) parentDomainName "DefaultDomain" (id=585) parentFirst false excludedRoots VirtualFile[0] (id=679) name "vfszip:/Users/kabir/sourcecontrol/jbossas/Branch_5_0/testsuite/output/lib/jaxws-endpoint-servlet.war" (id=666) policy VFSClassLoaderPolicy (id=680) requirementDependencies null requirements null space null system DefaultClassLoaderSystem (id=389) unit AbstractVFSDeploymentUnit (id=638) version Version (id=681) vfsRoots VirtualFile[2] (id=683) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209486#4209486 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209486

17 years, 1 month

1
0
0 / 0

[Design of JBoss Web Services] - Re: Stack independent addressing implementation

by richard.opalka＠jboss.com

We discussed this topic with Alessio and we have the following conclusions: We'll try to discuss this problem with JAX-WS representatives. From our point of view the only correct way of addressing this problem is to update JAX-WS spec so it will include required WS-A abstractions. It already includes some abstractions from WS-Addressing specification i.e. EndpointReference. Thus question is why other abstractions from that spec aren't part of the API? We think they have to be there to don't confuse JAX-WS users and don't make them tend to write proprietary code for each JAX-WS stack they're trying to integrate with. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4208911#4208911 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4208911

17 years, 1 month

1
0
0 / 0

[Design of JBoss Web Services] - Re: Stack independent addressing implementation

by adinn

anonymous wrote : | First of all we need to keep in mind basic J2EE principle here Write once run everywhere. Thus proprietary api is always wrong approach from this point of view. | Well, I really want my WSTX implementation to be container-independent and the hope was that JaxWS would provide that independence in the transport layer. However, I have no choice but to use the WSA management API which lies outside the spec -- the WS-* transaction specs requires manipulation of addressing properties. In the absence of any definition from the specs I still need some API to code to and it it would be better if we could provide just one API. If I were to build myself some facade classes to wrap around the CXF and JBoss WSA implementations of the WSA types I think I would still need to deploy stack-specific code at the interface to the stack (i.e. when I create addressing property values and when I install them or test for them on the client/server side of a connection). So, my code will end up being dual-image and deployment of my code will depend upon the WS deployment. Following this route seems doubly inappropriate in that the AddressingProperties classes are already facades. Is it possible to deploy the javax.xml.ws.* interfaces in the CXF WS release but configure them to use the CXF builder classes to populate them? In other words to use the implementation provided by the underlying stack but make it available via the same API as the native WS release. If we do choose an API it would be better if it were located in the javax package (although, strictly, we are not supposed to pollute this namespace with our own definitions). View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4208897#4208897 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4208897

17 years, 1 month

1
0
0 / 0

[Design of JBoss Web Services] - Re: Stack independent addressing implementation

by richard.opalka＠jboss.com

First of all we need to keep in mind basic J2EE principle here Write once run everywhere. Thus proprietary api is always wrong approach from this point of view. And because of wretched JAX-WS spec the first acceptable solution seems to be setting binding provider request properties and populating these properties to message payload via provided WS-A properties propagation JAX-WS handler. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4208841#4208841 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4208841

17 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbossws-dev February 2009