December 2007 - jbossws-dev - Jboss List Archives

[Design of JBoss Web Services] - Re: jUDDI tables dropped at server shutdown

by mvecera＠redhat.com

I would prefer fixing EAP's juddi. Supposing we deleted juddi-service.sar I can imagine the mess while applying patches for EAP and SOA to this (it must be possible to apply EAP patch to SOA-P)... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4113701#4113701 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4113701

16 years, 5 months

1
0
0 / 0

[Design of JBoss Web Services] - WSDLtoJava multiple Namespace to multiple package mapping

by mageshbk＠jboss.com

I am working on this JIRA http://jira.jboss.org/jira/browse/JBWS-1217 where customer submitted the fix. While committing the fix I found that due to the fix changes the package mapping has to be mandatorily defined for the type's namespace. For e.g., earlier this test case had a wstools config like below: | <configuration> | <wsdl-java location="resources/tools/jbws1079/Anonymous.wsdl" parameter-style="bare"> | <mapping file="anonymous-mapping.xml"/> | </wsdl-java> | </configuration> | This would generate all the code in the same package org.jboss.test.ws.jbws1079 But now due to the change for JBWS-1217 this tools config has to be re-written like this: | <configuration> | <global> | <package-namespace package="org.jboss.test.ws.jbws1079" namespace="http://test.jboss.org/ws/jbws1079/types"/> | </global> | <wsdl-java location="resources/tools/jbws1079/Anonymous.wsdl" parameter-style="bare"> | <mapping file="anonymous-mapping.xml"/> | </wsdl-java> | </configuration> | else the types will be generated into the package org.jboss.test.ws.jbws1079.types and the SEI in org.jboss.test.ws.jbws1079 I forsee no issues with this. Just that in future all types has to be namespace qualified explicitly into the appropriate package for them to be generated in the same package. Is this ok for the design. Just wanted an opinion. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4113451#4113451 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4113451

16 years, 5 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBWS-1858 + JBWS-1797: when to generate wsdl?

by richard.opalka＠jboss.com

Sorry, I was talking about JBWS-1797 ;-) RIchard View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4113297#4113297 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4113297

16 years, 5 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBWS-1858 + JBWS-1797: when to generate wsdl?

by richard.opalka＠jboss.com

"alessio.soldano(a)jboss.com" wrote : | Thus according to me the main point here is not moving the wsdl generation later, it's instead reading the servlet context-params earlier, during the deployment. Of course we could do both the changes, but having those params available (for example as properties in the DeploymentInfo) before the UMDM is generated would be enough (and is required before the EndpointLifeCycleDeploymentAspect is run). | What do you think about this? Hi Alessio, this is the cite from JBWS-1799 (Thomas investigation about this issue): In AS42 the servlet context params are not exposed through the AS WebMetaData and are hence not available when during deploy time the wsdl is generated. For these containers and maybe generally it needs to be investigated whether we can generate the wsdl at Endpoint.start(). At that point the config-name has been corrected in ServerEndpointMetaData according to this you should first investigate whether you are able to access context parameters during the deployment phase (using JBossAS deployment metadata objects). If it is doable, you will have no problems ;-) Richard View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4113296#4113296 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4113296

16 years, 5 months

1
0
0 / 0

[Design of JBoss Web Services] - ws-security code

by anil.saldhana＠jboss.com

I am wondering if the WS-Security code base can be isolated into a separate maven code base such that any extension happening at JBoss can make use of this separate project. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4113193#4113193 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4113193

16 years, 5 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBWS-1858 + JBWS-1797: when to generate wsdl?

by heiko.braun＠jboss.com

IMO any container (or deployment) dependent meta data should be processed and massaged into the SPI artifacts before transitioning into the actual stack. So I'd say what you suggest makes perfect sense. Process those bits earlier and find a good representation in the SPI artifacts. I didn't look at it myself, but the stack shouldnt deal with container meta data directly at all: | Container | SPI | Stack | Any pipe represents a transformation step of the meta data involved and a clear boundary. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4113181#4113181 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4113181

16 years, 5 months

1
0
0 / 0

2.0.3 Release planning

by Heiko Braun

Hi everybody, a quick heads up regarding the 2.0.3 release: * End of this week (14.12) is JIRA freeze. Please take a look at your current assignments and make sure it meets your dev planning. * I guess most of us will be on vacation from 22.12 - 07.01 * Code freeze is already 18.01. That means roundabout 15 days for development only The release is scheduled for 01.02.2008. /Heiko

16 years, 5 months

4
3
0 / 0

[Design of JBoss Web Services] - JBWS-1858 + JBWS-1797: when to generate wsdl?

by alessio.soldano＠jboss.com

I'm analyzing the http://jira.jboss.org/jira/browse/JBWS-1858 which is related to JBWS-1797. The main concern is generating and exposing the wsdl contract after the eventual servlet context-param properties have been read and the metadata has changed accordingly. As a matter of fact they can influence the wsdl (.NET friendly Endpoint...). Actually the wsdl creation is triggered during the create phase of the UnifiedMetaDataDeploymentAspect; either a new wsdl or the user provided one is selected, then the PublishContractDeploymentAspect publishes it. The new wsdl creation could be performed at some later stage, as far as I can see this would imply running the PublishContractDeploymentAspect and EagerInitializeDeploymentAspect later too, since they rely on the WSDLDefinition. This however is not going to solve the JBWS-1797 with AS42: currently the EndpointServlet gets the context-params from the its context during the first call to the endpoint, however at that time the endpoint has already been started (at the end of the deployment, by the EndpointLifeCycleDeploymentAspect). Thus according to me the main point here is not moving the wsdl generation later, it's instead reading the servlet context-params earlier, during the deployment. Of course we could do both the changes, but having those params available (for example as properties in the DeploymentInfo) before the UMDM is generated would be enough (and is required before the EndpointLifeCycleDeploymentAspect is run). What do you think about this? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4113145#4113145 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4113145

16 years, 5 months

1
0
0 / 0

Re: Hudson

by Magesh Kumar B

Hi Thomas/Others, Can I schedule/start/queue a hudson build myself? What is the username I need to use? I just want to avoid waiting for the build to get scheduled and then later see the results. Pardon me if this info is already passed around and if I have missed it. -Magesh

16 years, 5 months

1
0
0 / 0

[Design of JBoss Web Services] - JMS Endpoint - Message delivery starts before endpoint is re

by alessio.soldano＠jboss.com

I'm taking a look at the http://jira.jboss.org/jira/browse/JBWS-1324 issue; here are some thoughts about it we might want to discuss: - It's difficult to systematically reproduce this issue in a testcase; Darran, do you already have a testcase showing this behaviour? - Apart from this, I think the most straightforward solution here is to put the described workaround (the sleep) in the abstract JMSTransportSupport class, preventing the user from doing the same in every JMS endpoints. - Ideally it would be great to have these MDBs deployed with the message delivery disabled and enable it once the DefaultEndpoint is ready (let's say from a deployment aspect for example). However the only way I see to have a MDB deployed this way is to use the DeliveryActive attribute in the standard jboss bean configuration (invoker-proxy-binding -> proxy-factory-config -> MDBConfig). Moreover afaik this cannot be done with EJB3s (and I think soon we'll need them too). - Another workaround could be to have the message driven bean depend on something being deployed after it in the same sar archive (a queue for example), like in our org.jboss.test.ws.jaxrpc.samples.jmstransport sample. As far as I can see trying the sample, our endoint state goes to STARTED in the deployment start phase of the jar, when the EndpointLifecycleDeploymentAspect:Start is called. At that point the ejb service is waiting on the start of the queue specified in the sar archive, since the inner jar is deployed first. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4112970#4112970 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4112970

16 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbossws-dev December 2007