January 2007 - jboss-dev-forums - Jboss List Archives

[Design of JBoss Web Services] - Re: Using jbossws/trunk for jboss-5.0, jboss-4.2, jboss-4.0.

by dwin

thanks, another issue that I had was a class not found exception of ParameterMode but that was fixed when I manually moved over the jboss-rpc.jar to the third party lib folder and the lib folder for the app server. Not all tests passed but the vast majority of them did (99% to be exact) Just a question, when do you guys think there will be a stable binary release (beyond beta) for JBossWS (JAXWS) with JBoss 4.0.5? Also, there isn't much documentation for using JAXWS with wstools. I am trying to decipher it whether wstool supports wsimport and wsgen (like the GlassFish implementation) but I am guessing its not entirely there yet. again, thanks for the help View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001108#4001108 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001108

19 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: bean/mbean integration issue

by alesj

"adrian(a)jboss.org" wrote : | This interface is not correct. | PropertyMetaData and ParameterMetaData are POJO specific. | | This interface belongs in the dependency module that knows nothing about | POJOs/services. | | You need something like the DynamicMBean interface | | | Object get(String name) throws Throwable; | | void set(String name, Object value) throws Throwable; | | Object invoke(String name, String[] signature, Object[] parameters) throws Throwable; | | | Yes. I tried with this sort of impl. But I saw that in order to get the actual parameter values and their (String) types I needed a lot of target info - beanInfo, methodInfo, classloader, ... Which would bloat the interface. Is the target (Service, ...) always availabe to me for this sort of info? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001096#4001096 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001096

19 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: Are you considering an OSGi based micro kernel ?

by alesj

"c.vidal" wrote : | It looks like Alesj has taken the lead on the subject, that's great :) | You are always welcome to help: - http://anonsvn.jboss.org/repos/jbossas/projects/osgi/ It is still a work in progress, still a few things to figure out. And the whole testing environment. Rgds, Ales View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001089#4001089 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001089

19 years, 2 months

1
0
0 / 0

[Design of JBoss Web Services] - Future direction and state of the WSDLDefinitions API

by jason.greene＠jboss.com

Part of the JAX-WS work I did involved revamping the WSDLDefinitions API to be more accurate with WSDL 1.1 (there were many problems with the previous design that made it impossible to represent the mappings required by JAX-WS). I also brought the API inline with the current version of the WSDL 2.0, as many elements are missing. So basically the current version in trunk is highly focused towards WSDL 2.0. The reason for this is that we now only have one component that generates the model (WSDLGenerator), and the resulting model is capable of serializing to both 1.1 and 2.0 (as soon as the 2.0 writer is fully implemented[further down the roadmap]). This allows for interesting applications. For example, it would theoretically be possible to provide a conversion utility that would read a WSDL 1.1 file, and produce a WSDL 2.0 file by just reading it using WSDL11Reader, and writing it using the final WSDL20Writer. There is only one major difference that has to be accounted for, and that is the change of the RPC style in WSDL 2.0 to be the document/literal wrapped style. So basically the difference here is that there is no equivalent of a message in WSDL 2.0, which means that everything has to be expressed using schema. Therefore anything that used the RPC style in WSDL 1.1 would have to have its parts converted to a schema complexType before it could be serialized correctly. So when using this API, everything operates mainly from the 2.0 perspective. So I would recommend that anyone doing work on this API, or using it take a brief look at WSDL 2.0 spec to get an idea of how it should be used. All of the metadata builders can be looked at for examples as well. There also is some information that is needed for WSDL 1.1 that can't be expressed in 2.0, so in order to have a model that is capable of being serialized to both, you need to provide the extra 1.1 information, which would be ignored when producing a WSDL 2.0 document. For example, since WSDL 2.0 does not have a message component, the message name, and the part names are not used. So in this example, the WSDLInteraceMessageReference object (which is a WSDL 2.0 concept) contains additional properties for the WSDL 1.1 message name, and the part name. As mentioned above the RPC style in WSDL 2.0 is basically document/literal wrapped. This means there is conceptionally only once "part" as you think of it in WSDL 1.1 terms, and that one part maps to a complexType that contains the multiple "parameters". So to support serialization to 1.1 RPC style, there is the notion of a WSDLRPCPart. This is capable of being mapped to both. For WSDL 1.1 this would translate to a message part element, and for WSDL 2.0 this is just extra information about the schema element that represents the "part". Another difference is that headers were designed to be binding only, and are not part of the formal abstract contract which is represented in schema. So when using headers (or attachments) they must be represented directly on the binding API elements of WSDLDefinitions, and not the WSDLInterface. This is actually a loss of information in WSDL 2.0 that prevents determining whether a header is implicit or explicit. In WSDL 1.1 if the header was part of the message containing the body parts, it was assumed that the resulting java code should have this header bound to a parameter(explicit). If it was in a different message it was assumed to not be part of the main contract, and thus not bound to a java parameter, and instead up to a handler or the like to provide it. So in order to allow this information to be maintained when serializing/deserializing to WSDL 1.1 set/getIncludeInSignature is used on the WSDLSOAPHeader to indicate wheter or not it is implicit or explicit. There are a couple of things that still need to be improved. Originally the WSDLDefinitions API was designed to represent a single WSDL 2.0 file, so everything used NCNames. It has since been update to be a final infoset, and uses QNames, but the NCNames are still used in some places. These should all be removed. Also the writers should be updated to use either DOM, JDOM or StAX for writing the document. Currently they serialize everything on their own, which is a potential problem with character escaping. Also the code would be simpler and more maintainable if it relied on a framework to do the heavy lifting. Also everything is ran through DOM to pretty print the output anyway, so this would eliminate an extra parse phase. -Jason View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001087#4001087 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001087

19 years, 2 months

1
0
0 / 0

[Design of JBoss/Tomcat Integration] - Re: Webapp under root context eg. http://localhost/

by cococ

There are several ways to do this. If your webapp is part of an EAR file, then the webapp's context root can be defined in the EAR's META-INF/application.xml file (see: http://docs.jboss.org/jbossas/guides/webguide/r2/en/html_single/#d0e777). <application> | ... | <module> | <web> | <web-uri>my.war</web-uri> | <context-root>m</context-root> | </web> | </module> | </application> | If your webapp is not packaged in an EAR, but deployed as just a webapp, then the context-root can be defined in WEB-INF/jboss-web.xml of the webapp. <jboss-web> | <context-root>my</context-root> | </jboss-web> | You don't typically deploy a webapp inside of a SAR since this is a service archive (at least I'm not familiar with that practice), either wrap the webapp in an EAR, or deploy it singularly. Christopher View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001059#4001059 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001059

19 years, 2 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBWS-1260 - such a part must refer to an element named a

by jason.greene＠jboss.com

"darran.lofthouse(a)jboss.com" wrote : I am not sure if that is the case, this at your WSDL your message 'attachRequest' contains two message parts so based on the first requirement for a message to contain only a single part this should also be rejected so I am surprised you are not seeing that - I will have a look and see what happened to that check. | The rule is that it must contain only one part that is bound to body of the message. The service can still contain additional parts if the extra parts are bound to an attachment or a header. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001054#4001054 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001054

19 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: ServiceMetaData parsing needs to be pulled out of Servic

by scott.stark＠jboss.org

After the mc call this morning I realize that the problem with building the stable metadata view that the ManagedObject view maps to is that the ServiceMetaData is not what should be used. Adrian pointed out that all we have today is the dom model of the *-ds.xml in terms of an implementation independent model of a datasource. I'll spend a litte time on trying to use that, otherwise I will create a fake datasource deployer with a simple pojo model. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001052#4001052 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001052

19 years, 2 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBWS-1260 - such a part must refer to an element named a

by jason.greene＠jboss.com

"thomas.diesler(a)jboss.com" wrote : In that case a wsdl like this | AFAICS the requriment pertains only the the java realm and not to the abstract contract in wsdl. This is not in the BP since it only governs existing specifications namely WSDL 1.1, which does not have a mechanism to express this convention. The whole reason for the wrapped convention, is to fix the RPC style in WSDL 1.1 by overlaying the RPC requirements on top of a document/literal service. (This is the source of the operation name match requirement). So the intention is that a server component using the wrapped convention would provide hints to any client so that it would use this style as well. However since a WSDL extension was not introduced, the service still works with any thing that understands document/literal (since it is just a convention). So, by design, the wrapped convention is more restrictive than a normal document/literal bare service. The problem was fully addressed in WSDL 2.0, where the wrapped convention became the new RPC style. So, in WSDL 2.0, all of these rules and restrictions you see are officially part of the spec. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001051#4001051 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001051

19 years, 2 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Another way to write clustered singletons

by oglueck

You can also try and filter with MBeanServerNotificationFilterFactory for MBean registration notifications. See http://docs.jboss.org/jbossas/javadoc/4.0.5/system/org/jboss/system/filte... I am trying to figure out with that one when Axis has registered its JMX bean. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001042#4001042 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001042

19 years, 2 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBWS-1260 - such a part must refer to an element named a

by jason.greene＠jboss.com

"thomas.diesler(a)jboss.com" wrote : In that case a wsdl like this | | should work and the generated java method name should be paraList2 instead of invokeAttach. | Thats incorrect. The generated java method name (unless customized) always matches the operation name, it never matches the element name. Also it does not adhere to the wrapped convention so it must be treated as a bare parameter style service. Also, this WSDL violates BP 1.0 because it uses "type" on the part definition for a document/literal web service. It must be element. | <part name="attachmentContents" type="xsd:string"/> | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4001040#4001040 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4001040

19 years, 2 months

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

jboss-dev-forums January 2007