June 2007 - jbossws-dev - Jboss List Archives

[Design of JBoss Web Services] - Re: The JBossWS build is a joke - the project is unmaintaina

by adrian＠jboss.org

One other point. You shouldn't be using the main deployer to create webcontexts. You should just be adding WebMetaData to your deployment. That was one of the main reasons for the Deployers changes. A single deployment can be both a web deployment and an ejb deployment, exactly because this occurs in webservices. The hack to create a new deployment for the web-app is a hangover from the JBoss4 limitiations. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4059205#4059205 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4059205

16 years, 10 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: The JBossWS build is a joke - the project is unmaintaina

by adrian＠jboss.org

"thomas.diesler(a)jboss.com" wrote : I already updated to the new deployer architecture | | http://jbws.dyndns.org:8280/hudson/job/Core-Tests-AS-5.0/57/changes :-) Ok, but my other concerns still stand. 1) Fix the build so it is reproducable 2) Don't reinvent the deployers framework 3) Fix the error handling 4) Reuse the already developed code instead of re-inventing it and introducing alternate bugs. If it is doesn't quite do do what you want then add some new callbacks like the accepts() I added to the parsing deployers so EJB3 can do its hacks. :-) One example of (2) is how do I modify the webserivices metadata with a new deployer? I can't. I have to use a different api, the DeployersHook to do this. This is just stupid. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4059201#4059201 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4059201

16 years, 10 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: The JBossWS build is a joke - the project is unmaintaina

by adrian＠jboss.org

I'm going to go back to the jbossws codebase instead of the varia strategy and try to fix the build so at least it becomes reproducable. Once that is done, I'll do the updates for the new deployers. Then we can finally do a release and get webservices working again in the appserver. Even after this, there are lots of issues about whether webservices should be depending on things like ejb3 at all. It should certainly have access to its metadata for deployment purposes, which is one of the reasons we have started a "metadata" project so projects can share each others models. Webservices seems to have one (WebservicesMetaData) which should be moved there. I don't understand why you wrote your own parsing routines instead of using the ObjectModelParsing deployer. Well, actually I do, its because you're doing some stupid double parse where you first parse to DOM to check the namespace then parse again using JBossXB????? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4059197#4059197 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4059197

16 years, 10 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: The JBossWS build is a joke - the project is unmaintaina

by thomas.diesler＠jboss.com

I already updated to the new deployer architecture http://jbws.dyndns.org:8280/hudson/job/Core-Tests-AS-5.0/57/changes View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4059195#4059195 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4059195

16 years, 10 months

1
0
0 / 0

Prevent NPE with invalid jacc metaData

by Thomas Diesler

Anil, could you please verify 3. Prevent NPE with invalid jacc metaData http://jbws.dyndns.org:8280/hudson/job/AS-5.0/31/changes cheers -thomas -- xxxxxxxxxxxxxxxxxxxxxxxxxxxx Thomas Diesler Web Service Lead JBoss, a division of Red Hat xxxxxxxxxxxxxxxxxxxxxxxxxxxx

16 years, 10 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: The JBossWS build is a joke - the project is unmaintaina

by adrian＠jboss.org

Anyway, back to the reason why I want to modify the jbossws project. I'm trying to integrate the new deployer updates: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=112181 I started to copy the code into varia as a temporary measure so at least I know what versions I'm compiling over and the integration gets maintained in step with the JBossAS code, like EJB3. What do I find, you've reinvented the wheel again (the deployers framework) with something called DeployerHooks. Why?????? I also started commenting a number of other stupidities like using the Thread Context Classloader instead of the DeploymentUnit.getClassLoader() and the ever handling is the usual mess. e.g. aop has the same problem: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058739#4058739 But more importantly, the DeploymentContext is used everywhere! Even though this has been deprecated method from the start with a comment on getDeploymentContext() saying "think about it before using this method". Not only that it is referenced inside JBossWS itself, so I can't even just rewrite the deployers inside JBossAS (as a temporary measure) because the api is broken in jbossws-spi.jar I can understand you having your own abstraction for deployment that is a good thing. But not when you are just munging http://en.wikipedia.org/wiki/Munging somebody else's api and exposing implementation details that should never have been exposed. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4059193#4059193 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4059193

16 years, 10 months

1
0
0 / 0

[Design of JBoss Web Services] - The JBossWS build is a joke - the project is unmaintainable

by adrian＠jboss.org

To update jbossws to the new deployers, I must have had to modify at least three files that organise thirdparty dependencies. But even having done that, it didn't build the jboss50 integeration. So I went to that directory and did a build there, and I got this: | [ejort@warjort jboss50]$ ant | Buildfile: build.xml | | prepare: | | thirdparty-init: | | thirdparty-get: | | thirdparty-classpath: | | thirdparty: | | init: | | BUILD FAILED | /home/ejort/jbossws/integration/jboss50/build.xml:41: Not available: ${jboss50.home}/client/jboss-ejb3-client.jar | Why is it compiling over non-versioned jars??????!!!!!!! This makes the whole build unreproducable. How do I know which version of jboss-ejb3-client.jar I need to reproduce a customer problem from source? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4059190#4059190 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4059190

16 years, 10 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Setting the properties on the JAXBContext

by heiko.braun＠jboss.com

Just to complete the picture: There is a default API to create JAXBContext's now: | JAXBContextFactory.newInstance().createContext() | The default factory implementation is the one that works with BindingCustomizations: | CustomizableJAXBContextFactory.java | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058788#4058788 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4058788

16 years, 10 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Setting the properties on the JAXBContext

by heiko.braun＠jboss.com

OK Tom, both Thomas and I did agree that the API quickshot was a mess. I did a revamp the API, but the concepts we talked about did remain the same. The SPI now contains | Endpoint.addBindingCustomization (BindingCustomization) | BindingCustomization offers Map like access and will become a generic extension point for binding implementations and is not specific to any stack or binding framework. The native stack implements JAXB binding customization: | /** | * Supported JAXB 2.1 customizations. | */ | public class JAXBBindingCustomization extends BindingCustomization { | | // Use an alternative RuntimeAnnotationReader implementation | public final static String ANNOTATION_READER = JAXBRIContext.ANNOTATION_READER; | | // Reassign the default namespace URI to something else at the runtime | public final static String DEFAULT_NAMESPACE_REMAP = JAXBRIContext.DEFAULT_NAMESPACE_REMAP; | | // Enable the c14n marshalling support in the JAXBContext. | public final static String CANONICALIZATION_SUPPORT = JAXBRIContext.CANONICALIZATION_SUPPORT; | | } | It is recognized by the JAXBContextFactory, when set on the SPI Endpoint. This allows you to supply JAXB customizations at deploy time through an ESB specific deployment aspect (in JBossWS terms spi.deployment.Deployer). This particular deployment aspect should recognize ESB deployments and customize the JAXB marshalling for those endpoints only. I think this SPI change will stand the test of time and allows us to model future ESB requirements (i.e. programmatic deployment) as well. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058783#4058783 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4058783

16 years, 10 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Setting the properties on the JAXBContext

by tfennelly

OK, so after looking this a bit more, I still think we're good. Haven't made it all the way yet - have other issues. I just wanted to give ye a heads up Vs waiting until tomorrow. Some feedback on the SPI changes, specifically being able to reset the JAXBHandler via the Endpoint instance.... If I were you guys, I'd be a little scared of allowing something like the ESB (JBossWSAdapter) to do this. It's true that in many cases the JBossWSAdapter will only be doing this for endpoints that are "under it's control" from a deployment perspective. However, it's not impossible to use the JBossWSAdapter to access a webservice endpoint not under it's control (from a deployment perspective). In a situation like this, isn't it a bit dodgy to be allowing the JBossWSAdapter screw with details of an endpoint not "under its control". Perhaps it'd be better to only allow programmatic "overriding" of the installed JAXBHandler via the InvocationContext i.e. only on a per request basis. That's just something for you guys to decide on. I think I have it working for the ESB so I'm happy enough from that perspective, although I did have to implement a bit of a hack in an effort to avoid the above scenario (more below). This is just general API feedback. I'm trying to avoid the type scenario I outlined above by using the old reliable ThreadLocal (Grrrr) | private static class JBossESBJBossWSJAXBHandler implements JAXBHandler { | private static ThreadLocal<JAXBHandler> handlerTL = | new ThreadLocal<JAXBHandler>(); | private JAXBHandler installedJaxbHandler; | private JBossWSAdapter adapter; | | private JBossESBJBossWSJAXBHandler( | JAXBHandler installedJaxbHandler, JBossWSAdapter adapter) { | this.installedJaxbHandler = installedJaxbHandler; | this.adapter = adapter; | handlerTL.set(installedJaxbHandler); | } | | public JAXBContext getJAXBContext(Class[] classes) throws JAXBException { | return handlerTL.get().getJAXBContext(classes); | } | | /** | * This method helps ensure that only threads executing out of the | * JBossWSAdapter are supplied with JAXBContext instances from the | * JBossWSAdapter. We don't like the idea of not using the installed | * JAXBHandler for non ESB initiated JBossWS requests after the | * JBossWSAdapter has changed the JAXBHandler for the endpoint. | */ | private void useAdapterAsHandler() { | handlerTL.set(adapter); | } | | private void useInstalledHandler() { | handlerTL.set(installedJaxbHandler); | } | } | So the JBossWSAdapter is my real JAXBHandler and the class outlined above is just a way of toggling between the installed JAXBHandler and the JBossWSAdapter JAXBHandler via the useInstalledHandler and useAdapterAsHandler methods respectively. The JBossWSAdapter turns itself on as the handler for the current thread and when done turns itself off and switches the thread back to the installed handler. None of this poop would be required if I were setting the JBossWSAdapter as the JAXBHandler for the request only via the InvocationContext (or some other request scope object). Unless of course (I just thought of this), the CommonMessageContext only has a copy of the Endpoint, in which case we're OK and I don't need to worry about any of the above issue. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058380#4058380 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4058380

16 years, 10 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 June 2007