[Axis2] Fwd: binary and enumFacet are incompatible with unordered in ADBBeanTemplate
Forwarding with the Axis2 prefix. I nearly missed it :)
BTW I guess these changes are done by Dims and Thilina for MTOM
compatibility so I guess they are the best people to test what went
wrong here :)
On 9/6/06, Chuck Williams [EMAIL PROTECTED] wrote:
Hi Dims and Ajith,
I believe you guys added revisions 434331 and 436663 as part of a fix
for Axis2-1065. Unfortunately these changes break the build and the
template. E.g., the sforce enterprise wsdl generates bogus code and
kills a clean build.
Simply backing out the changes in these two revisions causes the build
to succeed and all tests to pass. However, I suspect this will regress
Axis2-1065 and the same type of problem exists for enumFacet.
The issue is this. For ordered property sets, the main property parsing
loop generates code like this (in pseudo-code notation):
if (elementName==name1) {
...
} else throw Unexpected subelement
if (elementName==name2) {
...
} else throw Unexpected subelement
...
While in the unordered case the same code looks like this:
while (!endElement) {
if (elementName==name1) {
...
}
else if (elementName==name2) {
...
}
...
}
The binary MTOM code that was added fills the role of one the embedded
if's but is not of the same form, not an if at all. This code works in
the first ordered case, but in the second unordered case it doesn't work
at all to have fixed code expecting to just read a binary value where
one of the if's is supposed to be. Also in the binary case in the
current template the else is still generated after the MTOM code that is
not an if, whence the syntax violation in the code generated for the
sforce wsdl, which evidently has a binary property in an unordered
property set.
I'm no expert on MTOM. Can't you still test that you've got the right
property (the binary property) by using the start-element name? For the
template to work in the unordered case, some test that you've got the
binary propery is essential. The existing template does not do this,
which can only work in the ordered case where you know you are at the
right position, and even in this case does not do the proper error
checking to verify this.
I would commit the attached template as axis2 passes all tests, but the
logs indicate you made the revisions that created this problem to fix
another problem and so I don't want to just back that out without
bringing this to your attention first.
Chuck
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Ajith Ranabahu
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: binary and enumFacet are incompatible with unordered in ADBBeanTemplate
As of this morning, build is not broken. Please get a fresh nightly
and try again. there was a backward compat flag problem which i fixed
yesterday.
-- dims
On 9/6/06, Chuck Williams [EMAIL PROTECTED] wrote:
Hi Dims and Ajith,
I believe you guys added revisions 434331 and 436663 as part of a fix
for Axis2-1065. Unfortunately these changes break the build and the
template. E.g., the sforce enterprise wsdl generates bogus code and
kills a clean build.
Simply backing out the changes in these two revisions causes the build
to succeed and all tests to pass. However, I suspect this will regress
Axis2-1065 and the same type of problem exists for enumFacet.
The issue is this. For ordered property sets, the main property parsing
loop generates code like this (in pseudo-code notation):
if (elementName==name1) {
...
} else throw Unexpected subelement
if (elementName==name2) {
...
} else throw Unexpected subelement
...
While in the unordered case the same code looks like this:
while (!endElement) {
if (elementName==name1) {
...
}
else if (elementName==name2) {
...
}
...
}
The binary MTOM code that was added fills the role of one the embedded
if's but is not of the same form, not an if at all. This code works in
the first ordered case, but in the second unordered case it doesn't work
at all to have fixed code expecting to just read a binary value where
one of the if's is supposed to be. Also in the binary case in the
current template the else is still generated after the MTOM code that is
not an if, whence the syntax violation in the code generated for the
sforce wsdl, which evidently has a binary property in an unordered
property set.
I'm no expert on MTOM. Can't you still test that you've got the right
property (the binary property) by using the start-element name? For the
template to work in the unordered case, some test that you've got the
binary propery is essential. The existing template does not do this,
which can only work in the ordered case where you know you are at the
right position, and even in this case does not do the proper error
checking to verify this.
I would commit the attached template as axis2 passes all tests, but the
logs indicate you made the revisions that created this problem to fix
another problem and so I don't want to just back that out without
bringing this to your attention first.
Chuck
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] *PLEASE* discuss before committing (Re: svn commit: r439555 - in /webservices/axis2/trunk/java/modules: kernel/src/org/apache/axis2/ kernel/src/org/apache/axis2/deployment/util/ kernel/src
Hi all, I think I now get what Saminda is trying to do. He's trying to improve the spring support and that may help in other frameworks as well. That's pretty cool. Its then a matter of implementation. See my comments inline. On 9/6/06, Saminda Abeyruwan [EMAIL PROTECTED] wrote: Hi Deepal, The best practice is to put the wsdl file into service archive file . 100% correct. Wouldn't it be cool to generate ?wsdl/?xsd if MR is *RPCMessageReceiver, when the service object supplier is ServiceObjectSupplier This is what I wondering ... these changes are to fix jira axis2-1102 , right ? RPC generation of the wsdl is one of the areas that took a long time to get right and was the source of a lot jiras. Is the one of the choices we have, ie, is it worth adding an interface to solve this issue ? I know there are other issues and I address them below, but this may need to stand on its own merit. Current Axis-spring module has SpringAppContextAwareObjectSupplier and SpringServletContextObjectSupplier would has it own scope and imho we have to write a applicationContex.xml according to them and it's pretty restrictive. Thus, naturally i want to write my own supplier with it's own helper parameters. What do you mean by it has its own scope , is it different from our four session scope ? Oh no. I didn't mean that. Sorry. For Ex; SpringServletContextObjectSupplier specialized in embedded version (war). Here, it expect to have spring.xml from web.xml. Now if some one wants to deploy a another spring related service to a running axis2.war instance with a completely different applicationContext.xml, is hot deployment really happen ?. These is what i meant by scope, Its limitations. Hot deployment most certainly can happen via Service.startUp() , with the axis2-spring*.jar and the springframeworks jar inside the aar . That way there is complete isolation between aar's , and hot deployment does happen the right way. I responded to a users question a couple weeks ago about this but I haven't documented it yet. It took a long time to get the classloader issues and load-on-startup issues working right, and at that point I liked what we had. I have to think thru and test whether the interface Saminda is proposing from the TCCL will affect what was working, ie complete service isolation and hot deployment on startUp . . Keep in mind the spring applicationContext.xml is just one of many ways you can configure spring, and I purposely tried to avoid axis2 getting too involved here. The list is long and OT. Saminda , with your change any one how write spring need to implement the new interface ? Oh no. They can simply use the available Supplier classes. Users really don't have to worry about it. Agreed. But if any user want to plug another framework to Axis2 to supply service objects, the service object supplier has to implement the proposed interface, otherwise the deployment engine wouldn't recognize it as a service object suppler and ignores it. Wouldn't that be fair enough ? Saminda, are you aware you can configure Spring in each aar seperately and do hot deployment? Are you still restricted doing it that way ? Have you tested whether the interface you propose affects that scenario ? Still, I want to make sure I'm addressing your concern. What can the deployment engine do with the interface that startUp() cannot do at deployment time ? Also, the spring support and ServiceObjectSupplier came about trying to solve a particular problem. I'm not sure planning for other frameworks without a particular one in mind is the right approach. I want to clarify that you've brought up issues I haven't thought about, and since there are a lot of ways to use spring and axis2 I appreciate the thought provoking ideas you have. Regards, Robert Saminda - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] *PLEASE* discuss before committing (Re: svn commit: r439555 - in /webservices/axis2/trunk/java/modules: kernel/src/org/apache/axis2/ kernel/src/org/apache/axis2/deployment/util/ kernel/src
Hot deployment most certainly can happen via Service.startUp() , with the axis2-spring*.jar and the springframeworks jar inside the aar . That way there is complete isolation between aar's , and hot deployment does happen the right way. I responded to a users question a couple weeks ago about this but I haven't documented it yet. It took a long time to get the classloader issues and load-on-startup issues working right, and at that point I liked what we had. I have to think thru and test whether the interface Saminda is proposing from the TCCL will affect what was working, ie complete service isolation and hot deployment on startUp . . Actually, that won't work. org.apache.axis2.ServiceObjectSupplier will not be visible inside the aar to axis2-spring*.jar . Will test later ... its independence day in Brazil and I'm off to the beach ;-) . Robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2-1117) wsdl2java generates invalid wsdl
wsdl2java generates invalid wsdl Key: AXIS2-1117 URL: http://issues.apache.org/jira/browse/AXIS2-1117 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Components: Tools Environment: Java 1.4.2, Axis2 nightly build from 9/7/2006 Reporter: Todd Doolittle I used wsdl2java to create a service. The wsdl I used contained anonymous inner complex types. The new WSDL that wsd2java created and put in the resource directory created the inner complex types with a name= attribute in the ComplextType tag which I believe is invalid. The full original WSDL is listed at the bottom. Here is a snippet of example WSDL to simplying illustrating the problem... Here are the type definitions. Notice the annonymous inner complex type for the address... xsd:element name=person xsd:complexType xsd:sequence xsd:element name=firstName type=xsd:string / xsd:element name=lastName type=xsd:string / xsd:element name=address nillable=true xsd:complexType xsd:sequence xsd:element name=address type=xsd:string / xsd:element name=city type=xsd:string / xsd:element name=state type=xsd:string / xsd:element name=zip type=xsd:int / /xsd:sequence /xsd:complexType /xsd:element /xsd:sequence /xsd:complexType /xsd:element After running wsdl2java to create a service, the WSDL is creates and puts in the resource directory would look like this snippet xsd:element name=person xsd:complexType xsd:sequence xsd:element name=firstName type=xsd:string / xsd:element name=lastName type=xsd:string / xsd:element name=address nillable=true xsd:complexType name=address_type1 xsd:sequence xsd:element name=address type=xsd:string / xsd:element name=city type=xsd:string / xsd:element name=state type=xsd:string / xsd:element name=zip type=xsd:int / /xsd:sequence /xsd:complexType /xsd:element /xsd:sequence /xsd:complexType /xsd:element Notice in the above snippet, wsdl2java added the name=address_type0 to the anonymous inner ComplexType for the address. I do not believe an inner complex type is allowed to have a name attribute. At least my IDE flags it as an error. Below is the real full WSDL I used with wsdl2java. Below that is the resulting wsdl that wsdl2java placed in the resource directory that appears to be invalid. Original WSDL... ?xml version=1.0 encoding=UTF-8 standalone=no ? wsdl:definitions xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/; name=POC targetNamespace=http://tempuri.org/; xmlns:fjs=http://tempuri.org/; xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; wsdl:types xsd:schema elementFormDefault=qualified targetNamespace=http://tempuri.org/; xmlns:s1=http://tempuri.org/; xsd:element name=lookup xsd:complexType xsd:sequence xsd:element maxOccurs=unbounded minOccurs=0 name=upc nillable=true type=xsd:string / /xsd:sequence xsd:attribute name=count type=xsd:int use=required / /xsd:complexType /xsd:element xsd:element name=GetinfoResponse xsd:complexType xsd:sequence xsd:element name=items nillable=true xsd:complexType xsd:sequence xsd:element maxOccurs=unbounded minOccurs=0 name=item nillable=true xsd:complexType xsd:sequence xsd:element name=ksn nillable=true type=xsd:int / xsd:element name=upc nillable=true type=xsd:string / xsd:element name=maintdt nillable=true type=xsd:date / xsd:element name=dpt nillable=true type=xsd:int / /xsd:sequence /xsd:complexType /xsd:element /xsd:sequence /xsd:complexType /xsd:element /xsd:sequence xsd:attribute name=count type=xsd:int use=required / /xsd:complexType /xsd:element /xsd:schema /wsdl:types wsdl:message name=GetinfoIn wsdl:part element=fjs:lookup name=parameters / /wsdl:message wsdl:message name=GetinfoOut wsdl:part element=fjs:GetinfoResponse name=parameters / /wsdl:message wsdl:portType name=POCPortType wsdl:operation name=Getinfo wsdl:input message=fjs:GetinfoIn name=lookup / wsdl:output message=fjs:GetinfoOut name=GetinfoResponse / /wsdl:operation /wsdl:portType wsdl:binding name=POCBinding type=fjs:POCPortType
[jira] Updated: (AXIS2-814) unwrapping support in codegen
[ http://issues.apache.org/jira/browse/AXIS2-814?page=all ] Davanum Srinivas updated AXIS2-814: --- Attachment: unwrap.wsdl wsdl i used for testing. unwrapping support in codegen - Key: AXIS2-814 URL: http://issues.apache.org/jira/browse/AXIS2-814 Project: Apache Axis 2.0 (Axis2) Issue Type: New Feature Reporter: Davanum Srinivas Assigned To: Eran Chinthaka Priority: Blocker Attachments: unwrap.wsdl Please see the discussion here: http://marc.theaimsgroup.com/?t=11500696423r=1w=2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-814) unwrapping support in codegen
[ http://issues.apache.org/jira/browse/AXIS2-814?page=comments#action_12433108 ] Davanum Srinivas commented on AXIS2-814: command used: java org.apache.axis2.wsdl.WSDL2Java -u -uri unwrap.wsdl -uw unwrapping support in codegen - Key: AXIS2-814 URL: http://issues.apache.org/jira/browse/AXIS2-814 Project: Apache Axis 2.0 (Axis2) Issue Type: New Feature Reporter: Davanum Srinivas Assigned To: Eran Chinthaka Priority: Blocker Attachments: unwrap.wsdl Please see the discussion here: http://marc.theaimsgroup.com/?t=11500696423r=1w=2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2-1118) Off by one error in SOAP 1.2 action processing
Off by one error in SOAP 1.2 action processing
--
Key: AXIS2-1118
URL: http://issues.apache.org/jira/browse/AXIS2-1118
Project: Apache Axis 2.0 (Axis2)
Issue Type: Bug
Components: transports
Reporter: Matt Lovett
Priority: Minor
While debugging a failing Sandesha unit test (the SOAPVersionTest), I was
getting failures to do with soap action mismatches. I've tracked the defect to
the following code in HTTPTransportUtils, around line 216:
String transientString =
contentType.substring(index, contentType.length());
int equal = transientString.indexOf(=);
int firstSemiColon = transientString.indexOf(;);
String soapAction; // This will contain in the
string
if (firstSemiColon -1) {
soapAction = transientString.substring(equal +
1, firstSemiColon - 1);
In my case with the string like: action=;
The substring cuts one too far, setting soapAction to:
Note there is no trailing any more, which then messes up the code that
attempts to trim quotes off
each end of the string.
The fix is trivial:
-soapAction = transientString.substring(equal +
1, firstSemiColon - 1);
+soapAction = transientString.substring(equal +
1, firstSemiColon);
Thanks
Matt
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2-1119) Dispatcher support for ServiceMode=MESSAGE annotation
Dispatcher support for ServiceMode=MESSAGE annotation - Key: AXIS2-1119 URL: http://issues.apache.org/jira/browse/AXIS2-1119 Project: Apache Axis 2.0 (Axis2) Issue Type: New Feature Reporter: Jeff Barrett The Dispatcher currently assumes ServiceMode=PAYLOAD (e.g. the Body of the message). MESSAGE mode support for ProviderT types of Source, SOAPMessage, and String needs to be added. I am working on a patch which I will submit shortly -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-814) unwrapping support in codegen
[ http://issues.apache.org/jira/browse/AXIS2-814?page=comments#action_12433111 ] Davanum Srinivas commented on AXIS2-814: Problem #1: Generated code does not compile. [javac] C:\junk\src\test\unwrap\UnwrappedServiceStub.java:13: test.unwrap.UnwrappedServiceStub is not abstract and does not override abstract method starttestMethod1(test.unwrap.TestMethod1,test.unwrap.UnwrappedServiceCallbackHandler) in test.unwrap.UnwrappedService [javac] public class UnwrappedServiceStub extends org.apache.axis2.client.Stub Problem #2: The generated stub method looks like this. Please note that the return parameter is not fixed at all. it should be a String as per the wsdl public test.unwrap.TestMethod1Response testMethod1(int param11, java.lang.String param12, float param13) Problem #3: If there are multiple parameters in the output then can we use the holders concept like in Axis1? thanks, dims unwrapping support in codegen - Key: AXIS2-814 URL: http://issues.apache.org/jira/browse/AXIS2-814 Project: Apache Axis 2.0 (Axis2) Issue Type: New Feature Reporter: Davanum Srinivas Assigned To: Eran Chinthaka Priority: Blocker Attachments: unwrap.wsdl Please see the discussion here: http://marc.theaimsgroup.com/?t=11500696423r=1w=2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2-1119) Dispatcher support for ServiceMode=MESSAGE annotation
[ http://issues.apache.org/jira/browse/AXIS2-1119?page=all ] Bill Nagy updated AXIS2-1119: - Component/s: jaxws Dispatcher support for ServiceMode=MESSAGE annotation - Key: AXIS2-1119 URL: http://issues.apache.org/jira/browse/AXIS2-1119 Project: Apache Axis 2.0 (Axis2) Issue Type: New Feature Components: jaxws Reporter: Jeff Barrett The Dispatcher currently assumes ServiceMode=PAYLOAD (e.g. the Body of the message). MESSAGE mode support for ProviderT types of Source, SOAPMessage, and String needs to be added. I am working on a patch which I will submit shortly -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (AXIS2-1118) Off by one error in SOAP 1.2 action processing
[ http://issues.apache.org/jira/browse/AXIS2-1118?page=all ]
Davanum Srinivas resolved AXIS2-1118.
-
Resolution: Fixed
Fixed. Thanks Matt.
-- dims
Off by one error in SOAP 1.2 action processing
--
Key: AXIS2-1118
URL: http://issues.apache.org/jira/browse/AXIS2-1118
Project: Apache Axis 2.0 (Axis2)
Issue Type: Bug
Components: transports
Reporter: Matt Lovett
Priority: Minor
While debugging a failing Sandesha unit test (the SOAPVersionTest), I was
getting failures to do with soap action mismatches. I've tracked the defect
to the following code in HTTPTransportUtils, around line 216:
String transientString =
contentType.substring(index, contentType.length());
int equal = transientString.indexOf(=);
int firstSemiColon = transientString.indexOf(;);
String soapAction; // This will contain in the
string
if (firstSemiColon -1) {
soapAction = transientString.substring(equal
+ 1, firstSemiColon - 1);
In my case with the string like: action=;
The substring cuts one too far, setting soapAction to:
Note there is no trailing any more, which then messes up the code that
attempts to trim quotes off
each end of the string.
The fix is trivial:
-soapAction = transientString.substring(equal
+ 1, firstSemiColon - 1);
+soapAction = transientString.substring(equal
+ 1, firstSemiColon);
Thanks
Matt
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
maxOccurs Interop Problem
am using axis 1.4 I have a complex type element called ArrayOfString WSDL Snippet xsd:complexType name=ArrayOfString xsd:sequence xsd:element name=string minOccurs=0 maxOccurs=unbounded type=xsd:string/ /xsd:sequence /xsd:complexType The client is C++ When the client is accessing the service its expected soap packet is stringTestSpec/string But when AXIS sends a soap Response it creates a following response itemTestSpec/item Can anybody Help Me .Thanks in advance. Regards, Amol Ambekar Skandsoft Technologies KnowNow! www.skandsoft.com +91 92235 11526
[jira] Created: (AXIS2-1120) Phases concept is too confusing - please change for v1.1
Phases concept is too confusing - please change for v1.1 Key: AXIS2-1120 URL: http://issues.apache.org/jira/browse/AXIS2-1120 Project: Apache Axis 2.0 (Axis2) Issue Type: Improvement Components: core Affects Versions: 1.0 Reporter: Thilo Frotscher Priority: Blocker With Axis2 1.0 it can easily happen that you engage a module with services without realizing it! This is because even if explicitly engaging a module with a *single* service or a *single* operation, its handlers will automatically be invoked for *all* services if they belong to a global phase. There's no warning messages or anything that prevent's you from doing this. IMHO this bevaviour is very confusing, especially for beginners. I think there are two possible solutions to this: - disallow engagement with single services or operations for all modules that contain handlers in global phases (at the very least, display a warning message that the module will actually be invoked for *all* services) - or make sure that handlers in global phases are *available* to all services, but will only be invoked for services that they were *explicitly* engaged with Either way, the release of Axis2 1.1 is a very good opportunity to change this behaviour. The later you do this, the more backwards compatibility might have to be sacrificed. I am sure that many users will vote for this change once the use of Axis2 in general and modules in particular is more widespread. There was a discussion about this on the mailing list, but somehow it died out: http://marc.theaimsgroup.com/?l=axis-devm=115394666310204w=2 Please consider making this change for v1.1 Thanks! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-1120) Phases concept is too confusing - please change for v1.1
[ http://issues.apache.org/jira/browse/AXIS2-1120?page=comments#action_12433125 ] Davanum Srinivas commented on AXIS2-1120: - -1 to change behavior. Yes, if we can add more documentation, that's ok. But definitely don't want to remove the concept. Phases concept is too confusing - please change for v1.1 Key: AXIS2-1120 URL: http://issues.apache.org/jira/browse/AXIS2-1120 Project: Apache Axis 2.0 (Axis2) Issue Type: Improvement Components: core Affects Versions: 1.0 Reporter: Thilo Frotscher Priority: Blocker With Axis2 1.0 it can easily happen that you engage a module with services without realizing it! This is because even if explicitly engaging a module with a *single* service or a *single* operation, its handlers will automatically be invoked for *all* services if they belong to a global phase. There's no warning messages or anything that prevent's you from doing this. IMHO this bevaviour is very confusing, especially for beginners. I think there are two possible solutions to this: - disallow engagement with single services or operations for all modules that contain handlers in global phases (at the very least, display a warning message that the module will actually be invoked for *all* services) - or make sure that handlers in global phases are *available* to all services, but will only be invoked for services that they were *explicitly* engaged with Either way, the release of Axis2 1.1 is a very good opportunity to change this behaviour. The later you do this, the more backwards compatibility might have to be sacrificed. I am sure that many users will vote for this change once the use of Axis2 in general and modules in particular is more widespread. There was a discussion about this on the mailing list, but somehow it died out: http://marc.theaimsgroup.com/?l=axis-devm=115394666310204w=2 Please consider making this change for v1.1 Thanks! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-814) unwrapping support in codegen
[ http://issues.apache.org/jira/browse/AXIS2-814?page=comments#action_12433128 ] Ajith Harshana Ranabahu commented on AXIS2-814: --- Originally when unwrapping is being done my focus was in the input. The change for the output can also be done but we've to consider the issue of multiple parameters (Yes perhaps we would need to bring back the holder concept) unwrapping support in codegen - Key: AXIS2-814 URL: http://issues.apache.org/jira/browse/AXIS2-814 Project: Apache Axis 2.0 (Axis2) Issue Type: New Feature Reporter: Davanum Srinivas Assigned To: Eran Chinthaka Priority: Blocker Attachments: unwrap.wsdl Please see the discussion here: http://marc.theaimsgroup.com/?t=11500696423r=1w=2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maxOccurs Interop Problem
This is a bug in Axis -- please file a bug report in JIRA. On 9/7/06, Amol Ambekar [EMAIL PROTECTED] wrote: am using axis 1.4 I have a complex type element called ArrayOfString WSDL Snippet xsd:complexType name=ArrayOfString xsd:sequence xsd:element name=string minOccurs=0 maxOccurs=unbounded type=xsd:string/ /xsd:sequence /xsd:complexType The client is C++ When the client is accessing the service it's expected soap packet is stringTestSpec/string But when AXIS sends a soap Response it creates a following response itemTestSpec/item Can anybody Help Me .Thanks in advance. Regards, Amol Ambekar Skandsoft Technologies KnowNow! www.skandsoft.com +91 92235 11526 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (AXIS2-1097) Add metadata support for WebServiceProvider and related annotations on provider-based service implementation class
[ http://issues.apache.org/jira/browse/AXIS2-1097?page=all ] Nick Gallardo closed AXIS2-1097. Resolution: Fixed Add metadata support for WebServiceProvider and related annotations on provider-based service implementation class -- Key: AXIS2-1097 URL: http://issues.apache.org/jira/browse/AXIS2-1097 Project: Apache Axis 2.0 (Axis2) Issue Type: New Feature Components: jaxws Reporter: Jeff Barrett Attachments: 1097_patch.txt Add support in the metadata layer and refactor the EndpointController and JavaBeanDispatcher and ProviderDispather classes for provider-based annotations: WebServiceProvider, ServiceMode, BindingType. I am working on a patch which I will submit shortly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (AXIS2-1098) JAXWSTest not running ProxyNonWrappedTests
[ http://issues.apache.org/jira/browse/AXIS2-1098?page=all ] Nick Gallardo closed AXIS2-1098. Resolution: Fixed JAXWSTest not running ProxyNonWrappedTests -- Key: AXIS2-1098 URL: http://issues.apache.org/jira/browse/AXIS2-1098 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Jeff Barrett Attachments: 1098_patch.txt The test has been commented out of JAXWSTest //suite.addTestSuite(ProxyNonWrappedTests.class); This was done in rev 437985 because that file doesn't exist in SVN. I will submit a patch to add the missing file and uncomment the test. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (AXIS2-1099) Asyc Feature for JAXWS proxy Doc/Lit non Wrap.
[ http://issues.apache.org/jira/browse/AXIS2-1099?page=all ] Nick Gallardo closed AXIS2-1099. Resolution: Fixed Asyc Feature for JAXWS proxy Doc/Lit non Wrap. -- Key: AXIS2-1099 URL: http://issues.apache.org/jira/browse/AXIS2-1099 Project: Apache Axis 2.0 (Axis2) Issue Type: New Feature Components: jaxws Reporter: Nikhil Thaker Priority: Minor Attachments: JIRA_1099_DocLitNONWrapAsyncSupport.txt I am adding support for proxy Doc/Lit non Wrap Async callback. I will also included test case for Async Callback. The test case uses Doc/Lit wrapped wsdl and uses a binding file with enableAsyncMapping to true and enableWrapperStyle to false. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (AXIS2-1115) Error while creating multiple instance of same service on same thread.
[ http://issues.apache.org/jira/browse/AXIS2-1115?page=all ] Nick Gallardo closed AXIS2-1115. Resolution: Fixed Error while creating multiple instance of same service on same thread. -- Key: AXIS2-1115 URL: http://issues.apache.org/jira/browse/AXIS2-1115 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws Reporter: Nikhil Thaker Attachments: JIRA_1115_DescriptionChanges.txt I receive the An error occurred while creating the ServiceClient exception when running junit test cases. This appears to happen when there are multiple instances of the same Service within the same thread. In this case, the previously configured servise should be picked up instead of reconfiguring a new one. Here's the JUnit Sample code: DocLitWrappedService service1 = new DocLitWrappedService(); service1.getDocLitWrappedPort(); DocLitWrappedProxy port1 = service2.getDocLitWrappedPort(); port1.twoWayTest(some test string); // this is ok DocLitWrappedService service2 = new DocLitWrappedService(); DocLitWrappedProxy port2 = service2.getDocLitWrappedPort(); port2.twoWayTest(some test string); // throws the exception Here's the stack trace: javax.xml.ws.WebServiceException: An error occurred while creating the ServiceClient. at org.apache.axis2.jaxws.ExceptionFactory.createWebServiceException(ExceptionFactory.java:217) at org.apache.axis2.jaxws.ExceptionFactory.makeWebServiceException(ExceptionFactory.java:81) at org.apache.axis2.jaxws.spi.ServiceDelegate.getServiceClient(ServiceDelegate.java:354) at org.apache.axis2.jaxws.client.proxy.BaseProxyHandler.InvokeSEIMethod(BaseProxyHandler.java:143) at org.apache.axis2.jaxws.client.proxy.BaseProxyHandler.invoke(BaseProxyHandler.java:121) at $Proxy6.twoWay(Unknown Source) at jaxws.proxy.wsfvt.test.DocLitWrappedTest.testTwoWay(DocLitWrappedTest.java:134) Caused by: org.apache.axis2.AxisFault: Two services can not have same name, a service with ProxyDocLitWrappedService already exists in the system at org.apache.axis2.client.ServiceClient.configureServiceClient(ServiceClient.java:111) at org.apache.axis2.client.ServiceClient.init(ServiceClient.java:95) at org.apache.axis2.jaxws.spi.ServiceDelegate.getServiceClient(ServiceDelegate.java:351) ... 22 more I will be attaching fix for this issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-1116) WSDL2Java with Xmlbeans binding is not generating classes for all schema
[
http://issues.apache.org/jira/browse/AXIS2-1116?page=comments#action_12433158 ]
Brennan Spies commented on AXIS2-1116:
--
Downloaded nightly build (2006-09-07), and it looks like all of the issues
except #2 have been fixed.
WSDL2Java with Xmlbeans binding is not generating classes for all schema
Key: AXIS2-1116
URL: http://issues.apache.org/jira/browse/AXIS2-1116
Project: Apache Axis 2.0 (Axis2)
Issue Type: Bug
Components: databinding
Affects Versions: 1.0
Environment: Windows XP, Axis 2.0 nightly build (2006-09-02)
Reporter: Brennan Spies
Attachments: files.zip
I have 3 XML Schemas that are used by my service definition in Query.wsdl. I
am specifying 'xmlbeans' as the databinding option and doing the code
generation with the following ant task (see attached for source):
codegen wsdlfilename=${basedir}/xml/Query.wsdl
output=${basedir} serverside=true
generateservicexml=true
packagename=com.ejgallo.workflow.service.query synconly=true
namespaceToPackages=urn:ejgallo:workflow:routing=com.ejgallo.workflow.service.routing,urn:ejgallo:worklfow:service=com.ejgallo.workflow.service,urn:ejgallo:workflow:service:query=com.ejgallo.workflow.service.query
databindingName=xmlbeans
serviceName=QueryWebService generateAllClasses=true
serverSideInterface=true
testcase=true unpackclasses=true/
There are 3 problems here:
1) Only one of the schema files, workflowTypes.xsd, has XMLBeans source
files generated for it, though the console output indicates that all 3 are
found/referenced. (No problem when Xmlbeans' ant task is used instead).
2) Under the /resources directory, the referenced schema files are generated
as 'xsd0.xsd', 'xsd1.xsd', and 'xsd2.xsd'. Because the original schema file
names are referenced in the WSDL and XSD files, this leads to the appropriate
files not being found when it is deployed as an .aar.
3) The 'namespaceToPackages' attribute on the ant task is not being honored,
leading the source files for the generated Xmlbeans classes to be the default
that Axis chooses for them based on the namespace.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2-1116) WSDL2Java with Xmlbeans binding is not generating classes for all schema
[ http://issues.apache.org/jira/browse/AXIS2-1116?page=all ]
Davanum Srinivas updated AXIS2-1116:
Priority: Blocker (was: Major)
WSDL2Java with Xmlbeans binding is not generating classes for all schema
Key: AXIS2-1116
URL: http://issues.apache.org/jira/browse/AXIS2-1116
Project: Apache Axis 2.0 (Axis2)
Issue Type: Bug
Components: databinding
Affects Versions: 1.0
Environment: Windows XP, Axis 2.0 nightly build (2006-09-02)
Reporter: Brennan Spies
Priority: Blocker
Attachments: files.zip
I have 3 XML Schemas that are used by my service definition in Query.wsdl. I
am specifying 'xmlbeans' as the databinding option and doing the code
generation with the following ant task (see attached for source):
codegen wsdlfilename=${basedir}/xml/Query.wsdl
output=${basedir} serverside=true
generateservicexml=true
packagename=com.ejgallo.workflow.service.query synconly=true
namespaceToPackages=urn:ejgallo:workflow:routing=com.ejgallo.workflow.service.routing,urn:ejgallo:worklfow:service=com.ejgallo.workflow.service,urn:ejgallo:workflow:service:query=com.ejgallo.workflow.service.query
databindingName=xmlbeans
serviceName=QueryWebService generateAllClasses=true
serverSideInterface=true
testcase=true unpackclasses=true/
There are 3 problems here:
1) Only one of the schema files, workflowTypes.xsd, has XMLBeans source
files generated for it, though the console output indicates that all 3 are
found/referenced. (No problem when Xmlbeans' ant task is used instead).
2) Under the /resources directory, the referenced schema files are generated
as 'xsd0.xsd', 'xsd1.xsd', and 'xsd2.xsd'. Because the original schema file
names are referenced in the WSDL and XSD files, this leads to the appropriate
files not being found when it is deployed as an .aar.
3) The 'namespaceToPackages' attribute on the ant task is not being honored,
leading the source files for the generated Xmlbeans classes to be the default
that Axis chooses for them based on the namespace.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] binary and enumFacet are incompatible with unordered in ADBBeanTemplate
Thanks Dims. I'm trying a build now. It takes a long time from here
due to all the maven library access delays (I already tried offline,
which failed hopefully only because a new library is requried).
The problems I've noted with the template remain. In the unordered case
the code inserts binary (or enumFacet) code into a looping structure
that looks for each property in any order. Each iteration of the loop
must check to see what property it is at and then load that value using
whatever method is correct. The code structure of the loop presumes
that each such property-loading code segment is an single if statement
that can be preceded by an else as there is no need to continue
checking properties in a single iteration once one is found. However,
the code generated for binary and enumFacet properties satisfies neither
of these criteria. This code does not check to see if it is at the
property it loads and it is not in the form of an if. This causes
invalid code to be generated. The binary and and enumFacet generated
code will only work in an ordered context.
With a binary MTOM property is it still possible to validate the
property by checking the name of the start element? If so, my fix
(which just backs out 434331 and 436663) will work. If not, then some
other test needs to be devised if binary attributes are to work in an
unordered context.
I'd be happy to fix if you could answer that question.
Thanks,
Chuck
Davanum Srinivas wrote on 09/07/2006 12:17 AM:
As of this morning, build is not broken. Please get a fresh nightly
and try again. there was a backward compat flag problem which i fixed
yesterday.
-- dims
On 9/6/06, Chuck Williams [EMAIL PROTECTED] wrote:
Hi Dims and Ajith,
I believe you guys added revisions 434331 and 436663 as part of a fix
for Axis2-1065. Unfortunately these changes break the build and the
template. E.g., the sforce enterprise wsdl generates bogus code and
kills a clean build.
Simply backing out the changes in these two revisions causes the build
to succeed and all tests to pass. However, I suspect this will regress
Axis2-1065 and the same type of problem exists for enumFacet.
The issue is this. For ordered property sets, the main property parsing
loop generates code like this (in pseudo-code notation):
if (elementName==name1) {
...
} else throw Unexpected subelement
if (elementName==name2) {
...
} else throw Unexpected subelement
...
While in the unordered case the same code looks like this:
while (!endElement) {
if (elementName==name1) {
...
}
else if (elementName==name2) {
...
}
...
}
The binary MTOM code that was added fills the role of one the embedded
if's but is not of the same form, not an if at all. This code works in
the first ordered case, but in the second unordered case it doesn't work
at all to have fixed code expecting to just read a binary value where
one of the if's is supposed to be. Also in the binary case in the
current template the else is still generated after the MTOM code that is
not an if, whence the syntax violation in the code generated for the
sforce wsdl, which evidently has a binary property in an unordered
property set.
I'm no expert on MTOM. Can't you still test that you've got the right
property (the binary property) by using the start-element name? For the
template to work in the unordered case, some test that you've got the
binary propery is essential. The existing template does not do this,
which can only work in the ordered case where you know you are at the
right position, and even in this case does not do the proper error
checking to verify this.
I would commit the attached template as axis2 passes all tests, but the
logs indicate you made the revisions that created this problem to fix
another problem and so I don't want to just back that out without
bringing this to your attention first.
Chuck
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-814) unwrapping support in codegen
[ http://issues.apache.org/jira/browse/AXIS2-814?page=comments#action_12433182 ] Eran Chinthaka commented on AXIS2-814: -- About problem #1. I just code-gen'ed for the Unwrap wsdl, implemented the skeleton, created and deployed the aar and successfully invoked using the stub. About poblem #2 #3 : Yep, I agree with Dims. But for the time being, can we only fix for the single parameter case and leave as it is for multiple param case? unwrapping support in codegen - Key: AXIS2-814 URL: http://issues.apache.org/jira/browse/AXIS2-814 Project: Apache Axis 2.0 (Axis2) Issue Type: New Feature Reporter: Davanum Srinivas Assigned To: Eran Chinthaka Priority: Blocker Attachments: unwrap.wsdl Please see the discussion here: http://marc.theaimsgroup.com/?t=11500696423r=1w=2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (AXIS2-1114) Adding support to handle NULL object in Proxy
[ http://issues.apache.org/jira/browse/AXIS2-1114?page=all ] Nick Gallardo closed AXIS2-1114. Resolution: Fixed Adding support to handle NULL object in Proxy - Key: AXIS2-1114 URL: http://issues.apache.org/jira/browse/AXIS2-1114 Project: Apache Axis 2.0 (Axis2) Issue Type: New Feature Components: jaxws Reporter: Nikhil Thaker Priority: Minor Attachments: JIRA_1114_Proxy_support_for_NULL.txt JAXWS Proxy DOC/LIT case did not handle null object being passed to the method parameter. I will be adding support to handle that, I will also add a test case for JAVA Bean endpoint with Proxy. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-1120) Phases concept is too confusing - please change for v1.1
[ http://issues.apache.org/jira/browse/AXIS2-1120?page=comments#action_12433189 ] Eran Chinthaka commented on AXIS2-1120: --- You might wanna read this : http://www.developer.com/java/web/article.php/3529321 Phases concept is too confusing - please change for v1.1 Key: AXIS2-1120 URL: http://issues.apache.org/jira/browse/AXIS2-1120 Project: Apache Axis 2.0 (Axis2) Issue Type: Improvement Components: core Affects Versions: 1.0 Reporter: Thilo Frotscher Priority: Blocker With Axis2 1.0 it can easily happen that you engage a module with services without realizing it! This is because even if explicitly engaging a module with a *single* service or a *single* operation, its handlers will automatically be invoked for *all* services if they belong to a global phase. There's no warning messages or anything that prevent's you from doing this. IMHO this bevaviour is very confusing, especially for beginners. I think there are two possible solutions to this: - disallow engagement with single services or operations for all modules that contain handlers in global phases (at the very least, display a warning message that the module will actually be invoked for *all* services) - or make sure that handlers in global phases are *available* to all services, but will only be invoked for services that they were *explicitly* engaged with Either way, the release of Axis2 1.1 is a very good opportunity to change this behaviour. The later you do this, the more backwards compatibility might have to be sacrificed. I am sure that many users will vote for this change once the use of Axis2 in general and modules in particular is more widespread. There was a discussion about this on the mailing list, but somehow it died out: http://marc.theaimsgroup.com/?l=axis-devm=115394666310204w=2 Please consider making this change for v1.1 Thanks! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-1120) Phases concept is too confusing - please change for v1.1
[ http://issues.apache.org/jira/browse/AXIS2-1120?page=comments#action_12433187 ] Eran Chinthaka commented on AXIS2-1120: --- -1 for the initial proposal from me too. if something is confusing, I hope the first solution is not to remove it, but to help improve it. So far, at least for me, phases are one of the best concepts in Axis2. Deducing from Dims' comment, I propose to create a JIRA requesting more documentation and resolving this issue. BTW, which one if confusing? - the phase concept itself? (Its just a stage in the execution framework, which consists of a set of handlers) - the implementation of phases in Axis2? - using phases? Phases concept is too confusing - please change for v1.1 Key: AXIS2-1120 URL: http://issues.apache.org/jira/browse/AXIS2-1120 Project: Apache Axis 2.0 (Axis2) Issue Type: Improvement Components: core Affects Versions: 1.0 Reporter: Thilo Frotscher Priority: Blocker With Axis2 1.0 it can easily happen that you engage a module with services without realizing it! This is because even if explicitly engaging a module with a *single* service or a *single* operation, its handlers will automatically be invoked for *all* services if they belong to a global phase. There's no warning messages or anything that prevent's you from doing this. IMHO this bevaviour is very confusing, especially for beginners. I think there are two possible solutions to this: - disallow engagement with single services or operations for all modules that contain handlers in global phases (at the very least, display a warning message that the module will actually be invoked for *all* services) - or make sure that handlers in global phases are *available* to all services, but will only be invoked for services that they were *explicitly* engaged with Either way, the release of Axis2 1.1 is a very good opportunity to change this behaviour. The later you do this, the more backwards compatibility might have to be sacrificed. I am sure that many users will vote for this change once the use of Axis2 in general and modules in particular is more widespread. There was a discussion about this on the mailing list, but somehow it died out: http://marc.theaimsgroup.com/?l=axis-devm=115394666310204w=2 Please consider making this change for v1.1 Thanks! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-814) unwrapping support in codegen
[ http://issues.apache.org/jira/browse/AXIS2-814?page=comments#action_12433205 ] Davanum Srinivas commented on AXIS2-814: hmm. ok about #1. If i see that problem again, then i'll holler :) #2, #3, Yes, please for 1.1 let's do the single param and log a INFO message if it return has multiple param. Basically the code will remain as is now (1 wrapper bean with multiple params for the return). -- dims unwrapping support in codegen - Key: AXIS2-814 URL: http://issues.apache.org/jira/browse/AXIS2-814 Project: Apache Axis 2.0 (Axis2) Issue Type: New Feature Reporter: Davanum Srinivas Assigned To: Eran Chinthaka Priority: Blocker Attachments: unwrap.wsdl Please see the discussion here: http://marc.theaimsgroup.com/?t=11500696423r=1w=2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2-1119) Dispatcher support for ServiceMode=MESSAGE annotation
[ http://issues.apache.org/jira/browse/AXIS2-1119?page=all ] Jeff Barrett updated AXIS2-1119: Attachment: 1119_patch.txt Fixed per Description. Dispatcher support for ServiceMode=MESSAGE annotation - Key: AXIS2-1119 URL: http://issues.apache.org/jira/browse/AXIS2-1119 Project: Apache Axis 2.0 (Axis2) Issue Type: New Feature Components: jaxws Reporter: Jeff Barrett Attachments: 1119_patch.txt The Dispatcher currently assumes ServiceMode=PAYLOAD (e.g. the Body of the message). MESSAGE mode support for ProviderT types of Source, SOAPMessage, and String needs to be added. I am working on a patch which I will submit shortly -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-1111) Add Maven 2 Plugins
[ http://issues.apache.org/jira/browse/AXIS2-?page=comments#action_12433218 ] Jochen Wiedmann commented on AXIS2-: Eran, I am not an Axis 2 developer. Don't know the Axis projects policies or whether I am nitpicking, but this is how I am used to behave from other projects. Add Maven 2 Plugins --- Key: AXIS2- URL: http://issues.apache.org/jira/browse/AXIS2- Project: Apache Axis 2.0 (Axis2) Issue Type: New Feature Components: Tools Reporter: Jochen Wiedmann Attachments: axis2-maven-tools.jar.bz2 Attached you find a first implementation of Maven 2 plugins for Axis 2: axis2-aar-maven-pluginCreates an aar file axis2-wsdl2code-maven-plugin Runs the wsdl2code generator axis2-java2wsdl-maven-plugin Runs the java2wsdl generator I'd like to contribute this to the Axis 2 project. Maintaining them would work best as soon as Axis 2 is itself built with Maven. The project needs more work. In particular, it lacks documentation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2-1121) binary and enumFacet are incompatible with unordered in ADBBeanTemplate
binary and enumFacet are incompatible with unordered in ADBBeanTemplate
---
Key: AXIS2-1121
URL: http://issues.apache.org/jira/browse/AXIS2-1121
Project: Apache Axis 2.0 (Axis2)
Issue Type: Bug
Reporter: Davanum Srinivas
Hi Dims and Ajith,
I believe you guys added revisions 434331 and 436663 as part of a fix
for Axis2-1065. Unfortunately these changes break the build and the
template. E.g., the sforce enterprise wsdl generates bogus code and
kills a clean build.
Simply backing out the changes in these two revisions causes the build
to succeed and all tests to pass. However, I suspect this will regress
Axis2-1065 and the same type of problem exists for enumFacet.
The issue is this. For ordered property sets, the main property parsing
loop generates code like this (in pseudo-code notation):
if (elementName==name1) {
...
} else throw Unexpected subelement
if (elementName==name2) {
...
} else throw Unexpected subelement
...
While in the unordered case the same code looks like this:
while (!endElement) {
if (elementName==name1) {
...
}
else if (elementName==name2) {
...
}
...
}
The binary MTOM code that was added fills the role of one the embedded
if's but is not of the same form, not an if at all. This code works in
the first ordered case, but in the second unordered case it doesn't work
at all to have fixed code expecting to just read a binary value where
one of the if's is supposed to be. Also in the binary case in the
current template the else is still generated after the MTOM code that is
not an if, whence the syntax violation in the code generated for the
sforce wsdl, which evidently has a binary property in an unordered
property set.
I'm no expert on MTOM. Can't you still test that you've got the right
property (the binary property) by using the start-element name? For the
template to work in the unordered case, some test that you've got the
binary propery is essential. The existing template does not do this,
which can only work in the ordered case where you know you are at the
right position, and even in this case does not do the proper error
checking to verify this.
I would commit the attached template as axis2 passes all tests, but the
logs indicate you made the revisions that created this problem to fix
another problem and so I don't want to just back that out without
bringing this to your attention first.
Chuck
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] binary and enumFacet are incompatible with unordered in ADBBeanTemplate
I've added a JIRA issue:
http://issues.apache.org/jira/browse/AXIS2-1121
thanks,
-- dims
On 9/7/06, Chuck Williams [EMAIL PROTECTED] wrote:
Thanks Dims. I'm trying a build now. It takes a long time from here
due to all the maven library access delays (I already tried offline,
which failed hopefully only because a new library is requried).
The problems I've noted with the template remain. In the unordered case
the code inserts binary (or enumFacet) code into a looping structure
that looks for each property in any order. Each iteration of the loop
must check to see what property it is at and then load that value using
whatever method is correct. The code structure of the loop presumes
that each such property-loading code segment is an single if statement
that can be preceded by an else as there is no need to continue
checking properties in a single iteration once one is found. However,
the code generated for binary and enumFacet properties satisfies neither
of these criteria. This code does not check to see if it is at the
property it loads and it is not in the form of an if. This causes
invalid code to be generated. The binary and and enumFacet generated
code will only work in an ordered context.
With a binary MTOM property is it still possible to validate the
property by checking the name of the start element? If so, my fix
(which just backs out 434331 and 436663) will work. If not, then some
other test needs to be devised if binary attributes are to work in an
unordered context.
I'd be happy to fix if you could answer that question.
Thanks,
Chuck
Davanum Srinivas wrote on 09/07/2006 12:17 AM:
As of this morning, build is not broken. Please get a fresh nightly
and try again. there was a backward compat flag problem which i fixed
yesterday.
-- dims
On 9/6/06, Chuck Williams [EMAIL PROTECTED] wrote:
Hi Dims and Ajith,
I believe you guys added revisions 434331 and 436663 as part of a fix
for Axis2-1065. Unfortunately these changes break the build and the
template. E.g., the sforce enterprise wsdl generates bogus code and
kills a clean build.
Simply backing out the changes in these two revisions causes the build
to succeed and all tests to pass. However, I suspect this will regress
Axis2-1065 and the same type of problem exists for enumFacet.
The issue is this. For ordered property sets, the main property parsing
loop generates code like this (in pseudo-code notation):
if (elementName==name1) {
...
} else throw Unexpected subelement
if (elementName==name2) {
...
} else throw Unexpected subelement
...
While in the unordered case the same code looks like this:
while (!endElement) {
if (elementName==name1) {
...
}
else if (elementName==name2) {
...
}
...
}
The binary MTOM code that was added fills the role of one the embedded
if's but is not of the same form, not an if at all. This code works in
the first ordered case, but in the second unordered case it doesn't work
at all to have fixed code expecting to just read a binary value where
one of the if's is supposed to be. Also in the binary case in the
current template the else is still generated after the MTOM code that is
not an if, whence the syntax violation in the code generated for the
sforce wsdl, which evidently has a binary property in an unordered
property set.
I'm no expert on MTOM. Can't you still test that you've got the right
property (the binary property) by using the start-element name? For the
template to work in the unordered case, some test that you've got the
binary propery is essential. The existing template does not do this,
which can only work in the ordered case where you know you are at the
right position, and even in this case does not do the proper error
checking to verify this.
I would commit the attached template as axis2 passes all tests, but the
logs indicate you made the revisions that created this problem to fix
another problem and so I don't want to just back that out without
bringing this to your attention first.
Chuck
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-1121) binary and enumFacet are incompatible with unordered in ADBBeanTemplate
[
http://issues.apache.org/jira/browse/AXIS2-1121?page=comments#action_12433224 ]
Davanum Srinivas commented on AXIS2-1121:
-
Thanks Dims. I'm trying a build now. It takes a long time from here
due to all the maven library access delays (I already tried offline,
which failed hopefully only because a new library is requried).
The problems I've noted with the template remain. In the unordered case
the code inserts binary (or enumFacet) code into a looping structure
that looks for each property in any order. Each iteration of the loop
must check to see what property it is at and then load that value using
whatever method is correct. The code structure of the loop presumes
that each such property-loading code segment is an single if statement
that can be preceded by an else as there is no need to continue
checking properties in a single iteration once one is found. However,
the code generated for binary and enumFacet properties satisfies neither
of these criteria. This code does not check to see if it is at the
property it loads and it is not in the form of an if. This causes
invalid code to be generated. The binary and and enumFacet generated
code will only work in an ordered context.
With a binary MTOM property is it still possible to validate the
property by checking the name of the start element? If so, my fix
(which just backs out 434331 and 436663) will work. If not, then some
other test needs to be devised if binary attributes are to work in an
unordered context.
I'd be happy to fix if you could answer that question.
Thanks,
Chuck
binary and enumFacet are incompatible with unordered in ADBBeanTemplate
---
Key: AXIS2-1121
URL: http://issues.apache.org/jira/browse/AXIS2-1121
Project: Apache Axis 2.0 (Axis2)
Issue Type: Bug
Reporter: Davanum Srinivas
Hi Dims and Ajith,
I believe you guys added revisions 434331 and 436663 as part of a fix
for Axis2-1065. Unfortunately these changes break the build and the
template. E.g., the sforce enterprise wsdl generates bogus code and
kills a clean build.
Simply backing out the changes in these two revisions causes the build
to succeed and all tests to pass. However, I suspect this will regress
Axis2-1065 and the same type of problem exists for enumFacet.
The issue is this. For ordered property sets, the main property parsing
loop generates code like this (in pseudo-code notation):
if (elementName==name1) {
...
} else throw Unexpected subelement
if (elementName==name2) {
...
} else throw Unexpected subelement
...
While in the unordered case the same code looks like this:
while (!endElement) {
if (elementName==name1) {
...
}
else if (elementName==name2) {
...
}
...
}
The binary MTOM code that was added fills the role of one the embedded
if's but is not of the same form, not an if at all. This code works in
the first ordered case, but in the second unordered case it doesn't work
at all to have fixed code expecting to just read a binary value where
one of the if's is supposed to be. Also in the binary case in the
current template the else is still generated after the MTOM code that is
not an if, whence the syntax violation in the code generated for the
sforce wsdl, which evidently has a binary property in an unordered
property set.
I'm no expert on MTOM. Can't you still test that you've got the right
property (the binary property) by using the start-element name? For the
template to work in the unordered case, some test that you've got the
binary propery is essential. The existing template does not do this,
which can only work in the ordered case where you know you are at the
right position, and even in this case does not do the proper error
checking to verify this.
I would commit the attached template as axis2 passes all tests, but the
logs indicate you made the revisions that created this problem to fix
another problem and so I don't want to just back that out without
bringing this to your attention first.
Chuck
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (AXIS2-1121) binary and enumFacet are incompatible with unordered in ADBBeanTemplate
[ http://issues.apache.org/jira/browse/AXIS2-1121?page=all ]
Davanum Srinivas resolved AXIS2-1121.
-
Resolution: Fixed
Fixed. Please see http://svn.apache.org/viewvc?view=revrevision=441219.
Basically i reverted the 2 checkins 436663 and 434331 and in the case of binary
won't check the propQName.
Will this work for you?
thanks,
dims
binary and enumFacet are incompatible with unordered in ADBBeanTemplate
---
Key: AXIS2-1121
URL: http://issues.apache.org/jira/browse/AXIS2-1121
Project: Apache Axis 2.0 (Axis2)
Issue Type: Bug
Reporter: Davanum Srinivas
Hi Dims and Ajith,
I believe you guys added revisions 434331 and 436663 as part of a fix
for Axis2-1065. Unfortunately these changes break the build and the
template. E.g., the sforce enterprise wsdl generates bogus code and
kills a clean build.
Simply backing out the changes in these two revisions causes the build
to succeed and all tests to pass. However, I suspect this will regress
Axis2-1065 and the same type of problem exists for enumFacet.
The issue is this. For ordered property sets, the main property parsing
loop generates code like this (in pseudo-code notation):
if (elementName==name1) {
...
} else throw Unexpected subelement
if (elementName==name2) {
...
} else throw Unexpected subelement
...
While in the unordered case the same code looks like this:
while (!endElement) {
if (elementName==name1) {
...
}
else if (elementName==name2) {
...
}
...
}
The binary MTOM code that was added fills the role of one the embedded
if's but is not of the same form, not an if at all. This code works in
the first ordered case, but in the second unordered case it doesn't work
at all to have fixed code expecting to just read a binary value where
one of the if's is supposed to be. Also in the binary case in the
current template the else is still generated after the MTOM code that is
not an if, whence the syntax violation in the code generated for the
sforce wsdl, which evidently has a binary property in an unordered
property set.
I'm no expert on MTOM. Can't you still test that you've got the right
property (the binary property) by using the start-element name? For the
template to work in the unordered case, some test that you've got the
binary propery is essential. The existing template does not do this,
which can only work in the ordered case where you know you are at the
right position, and even in this case does not do the proper error
checking to verify this.
I would commit the attached template as axis2 passes all tests, but the
logs indicate you made the revisions that created this problem to fix
another problem and so I don't want to just back that out without
bringing this to your attention first.
Chuck
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Axis2] binary and enumFacet are incompatible with unordered in ADBBeanTemplate
And checked in a fix as well.
-- dims
On 9/7/06, Davanum Srinivas [EMAIL PROTECTED] wrote:
I've added a JIRA issue:
http://issues.apache.org/jira/browse/AXIS2-1121
thanks,
-- dims
On 9/7/06, Chuck Williams [EMAIL PROTECTED] wrote:
Thanks Dims. I'm trying a build now. It takes a long time from here
due to all the maven library access delays (I already tried offline,
which failed hopefully only because a new library is requried).
The problems I've noted with the template remain. In the unordered case
the code inserts binary (or enumFacet) code into a looping structure
that looks for each property in any order. Each iteration of the loop
must check to see what property it is at and then load that value using
whatever method is correct. The code structure of the loop presumes
that each such property-loading code segment is an single if statement
that can be preceded by an else as there is no need to continue
checking properties in a single iteration once one is found. However,
the code generated for binary and enumFacet properties satisfies neither
of these criteria. This code does not check to see if it is at the
property it loads and it is not in the form of an if. This causes
invalid code to be generated. The binary and and enumFacet generated
code will only work in an ordered context.
With a binary MTOM property is it still possible to validate the
property by checking the name of the start element? If so, my fix
(which just backs out 434331 and 436663) will work. If not, then some
other test needs to be devised if binary attributes are to work in an
unordered context.
I'd be happy to fix if you could answer that question.
Thanks,
Chuck
Davanum Srinivas wrote on 09/07/2006 12:17 AM:
As of this morning, build is not broken. Please get a fresh nightly
and try again. there was a backward compat flag problem which i fixed
yesterday.
-- dims
On 9/6/06, Chuck Williams [EMAIL PROTECTED] wrote:
Hi Dims and Ajith,
I believe you guys added revisions 434331 and 436663 as part of a fix
for Axis2-1065. Unfortunately these changes break the build and the
template. E.g., the sforce enterprise wsdl generates bogus code and
kills a clean build.
Simply backing out the changes in these two revisions causes the build
to succeed and all tests to pass. However, I suspect this will regress
Axis2-1065 and the same type of problem exists for enumFacet.
The issue is this. For ordered property sets, the main property parsing
loop generates code like this (in pseudo-code notation):
if (elementName==name1) {
...
} else throw Unexpected subelement
if (elementName==name2) {
...
} else throw Unexpected subelement
...
While in the unordered case the same code looks like this:
while (!endElement) {
if (elementName==name1) {
...
}
else if (elementName==name2) {
...
}
...
}
The binary MTOM code that was added fills the role of one the embedded
if's but is not of the same form, not an if at all. This code works in
the first ordered case, but in the second unordered case it doesn't work
at all to have fixed code expecting to just read a binary value where
one of the if's is supposed to be. Also in the binary case in the
current template the else is still generated after the MTOM code that is
not an if, whence the syntax violation in the code generated for the
sforce wsdl, which evidently has a binary property in an unordered
property set.
I'm no expert on MTOM. Can't you still test that you've got the right
property (the binary property) by using the start-element name? For the
template to work in the unordered case, some test that you've got the
binary propery is essential. The existing template does not do this,
which can only work in the ordered case where you know you are at the
right position, and even in this case does not do the proper error
checking to verify this.
I would commit the attached template as axis2 passes all tests, but the
logs indicate you made the revisions that created this problem to fix
another problem and so I don't want to just back that out without
bringing this to your attention first.
Chuck
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
--
Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2-1122) service?wsdl returns error in conjunction with the startUp() method
service?wsdl returns error in conjunction with the startUp() method
---
Key: AXIS2-1122
URL: http://issues.apache.org/jira/browse/AXIS2-1122
Project: Apache Axis 2.0 (Axis2)
Issue Type: Test
Environment: WinXP, Java 1.5.0_06, Tomcat 5.5.17, Axis2 nightly build
(07-Sep-2006)
Reporter: Christian Mohr
Attachments: TestService.aar
The attached aar file contains a scope=application service that implements
the org.apache.axis2.engine.Service interface. This includes implementation of
the method
- public void startUp(ConfigurationContext ctx, AxisService service)
as described in issue AXIS2-1033.
The deployment of the aar works but when I try to access the generated WSDL via
TestService?wsdl the following error is returned:
error
descriptionUnable to generate WSDL for this service/description
reasonEither user has not dropped the wsdl into META-INF or
operations use message receivers other than RPC./reason
/error
I can fix this by commenting out the startUp() method (which implies not to
implement the Service interface) but I need this functionality.
TestService:
--
public class TestService implements org.apache.axis2.engine.Service {
public void destroy(ServiceContext ctx) {}
public void init(ServiceContext ctx) {}
public void setOperationContext(OperationContext ctx) {}
public void startUp(ConfigurationContext ctx, AxisService service) {}
public String echo(String s){ return s; }
}
services.xml:
--
service name=TestService scope=application
descriptionTest web service./description
parameter name=ServiceClass
locked=falsede.cmohr.services.TestService/parameter
parameter name=load-on-startup locked=falsetrue/parameter
operation name=echo
messageReceiver
class=org.apache.axis2.rpc.receivers.RPCMessageReceiver/
/operation
/service
Can you help me with this problem?
Thanks
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-1121) binary and enumFacet are incompatible with unordered in ADBBeanTemplate
[
http://issues.apache.org/jira/browse/AXIS2-1121?page=comments#action_12433257 ]
Chuck Williams commented on AXIS2-1121:
---
Dims,
Thanks for making this update.
I still have not managed to get a successful build (last attempt failed tests
in the security scenarios due to check-ins today), but have reviewed the
changes to the template.
I see that you explicitly did not check for being at the right property in the
unordered case (omitted the test of the start element name) and so presume that
for some reason this is not possible. This means the binary property code will
be evaluated on every iteration of the loop for any container with at least one
binary property. I don't see how this could work. In the sforce wsdl that
failed yesterday, it has an unordered type with both binary and non-binary
properties. The unordered property parsing loop can only work if it can detect
when it has reached the binary property. If the start element name cannot be
used for this, is there some other test that can?
I wrote the portions of the template that pertain to the unordered case and
understand it well, but I don't understand MTOM fully. I've read the spec and
don't see why testing the start element name cannot be done. If you could
explain how to test that the binary property has been reached I could fix the
the template.
binary and enumFacet are incompatible with unordered in ADBBeanTemplate
---
Key: AXIS2-1121
URL: http://issues.apache.org/jira/browse/AXIS2-1121
Project: Apache Axis 2.0 (Axis2)
Issue Type: Bug
Reporter: Davanum Srinivas
Hi Dims and Ajith,
I believe you guys added revisions 434331 and 436663 as part of a fix
for Axis2-1065. Unfortunately these changes break the build and the
template. E.g., the sforce enterprise wsdl generates bogus code and
kills a clean build.
Simply backing out the changes in these two revisions causes the build
to succeed and all tests to pass. However, I suspect this will regress
Axis2-1065 and the same type of problem exists for enumFacet.
The issue is this. For ordered property sets, the main property parsing
loop generates code like this (in pseudo-code notation):
if (elementName==name1) {
...
} else throw Unexpected subelement
if (elementName==name2) {
...
} else throw Unexpected subelement
...
While in the unordered case the same code looks like this:
while (!endElement) {
if (elementName==name1) {
...
}
else if (elementName==name2) {
...
}
...
}
The binary MTOM code that was added fills the role of one the embedded
if's but is not of the same form, not an if at all. This code works in
the first ordered case, but in the second unordered case it doesn't work
at all to have fixed code expecting to just read a binary value where
one of the if's is supposed to be. Also in the binary case in the
current template the else is still generated after the MTOM code that is
not an if, whence the syntax violation in the code generated for the
sforce wsdl, which evidently has a binary property in an unordered
property set.
I'm no expert on MTOM. Can't you still test that you've got the right
property (the binary property) by using the start-element name? For the
template to work in the unordered case, some test that you've got the
binary propery is essential. The existing template does not do this,
which can only work in the ordered case where you know you are at the
right position, and even in this case does not do the proper error
checking to verify this.
I would commit the attached template as axis2 passes all tests, but the
logs indicate you made the revisions that created this problem to fix
another problem and so I don't want to just back that out without
bringing this to your attention first.
Chuck
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (AXIS2-1121) binary and enumFacet are incompatible with unordered in ADBBeanTemplate
[ http://issues.apache.org/jira/browse/AXIS2-1121?page=all ]
Davanum Srinivas reopened AXIS2-1121:
-
binary and enumFacet are incompatible with unordered in ADBBeanTemplate
---
Key: AXIS2-1121
URL: http://issues.apache.org/jira/browse/AXIS2-1121
Project: Apache Axis 2.0 (Axis2)
Issue Type: Bug
Reporter: Davanum Srinivas
Hi Dims and Ajith,
I believe you guys added revisions 434331 and 436663 as part of a fix
for Axis2-1065. Unfortunately these changes break the build and the
template. E.g., the sforce enterprise wsdl generates bogus code and
kills a clean build.
Simply backing out the changes in these two revisions causes the build
to succeed and all tests to pass. However, I suspect this will regress
Axis2-1065 and the same type of problem exists for enumFacet.
The issue is this. For ordered property sets, the main property parsing
loop generates code like this (in pseudo-code notation):
if (elementName==name1) {
...
} else throw Unexpected subelement
if (elementName==name2) {
...
} else throw Unexpected subelement
...
While in the unordered case the same code looks like this:
while (!endElement) {
if (elementName==name1) {
...
}
else if (elementName==name2) {
...
}
...
}
The binary MTOM code that was added fills the role of one the embedded
if's but is not of the same form, not an if at all. This code works in
the first ordered case, but in the second unordered case it doesn't work
at all to have fixed code expecting to just read a binary value where
one of the if's is supposed to be. Also in the binary case in the
current template the else is still generated after the MTOM code that is
not an if, whence the syntax violation in the code generated for the
sforce wsdl, which evidently has a binary property in an unordered
property set.
I'm no expert on MTOM. Can't you still test that you've got the right
property (the binary property) by using the start-element name? For the
template to work in the unordered case, some test that you've got the
binary propery is essential. The existing template does not do this,
which can only work in the ordered case where you know you are at the
right position, and even in this case does not do the proper error
checking to verify this.
I would commit the attached template as axis2 passes all tests, but the
logs indicate you made the revisions that created this problem to fix
another problem and so I don't want to just back that out without
bringing this to your attention first.
Chuck
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DIME support in Axis 2
Hello, Due to a brief discussion on the user's list, where I was told that though DIME support had not been added (yet) to Axis 2, it shouldn't be too much trouble to do so, I thought I would subscribe to the developer's list and ask you developers what all is involved with integrating DIME support. The lack of DIME support is my only obstacle to using Axis 2, so if providing it wouldn't completely consume the greater project I am involved with, this very well might be something I could contribute. Is there anyone out there that could have a short discussion with me on what they think would be involved with integrating DIME support? Brad - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (AXIS2-1111) Add Maven 2 Plugins
[ http://issues.apache.org/jira/browse/AXIS2-?page=all ] Davanum Srinivas resolved AXIS2-. - Resolution: Fixed folks, i checked it in under modules\tool. next thing is to get the other stuff like eclipse/idea and ant plugins to build using Axis2. -- dims Add Maven 2 Plugins --- Key: AXIS2- URL: http://issues.apache.org/jira/browse/AXIS2- Project: Apache Axis 2.0 (Axis2) Issue Type: New Feature Components: Tools Reporter: Jochen Wiedmann Attachments: axis2-maven-tools.jar.bz2 Attached you find a first implementation of Maven 2 plugins for Axis 2: axis2-aar-maven-pluginCreates an aar file axis2-wsdl2code-maven-plugin Runs the wsdl2code generator axis2-java2wsdl-maven-plugin Runs the java2wsdl generator I'd like to contribute this to the Axis 2 project. Maintaining them would work best as soon as Axis 2 is itself built with Maven. The project needs more work. In particular, it lacks documentation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-1110) Java 2 Security
[ http://issues.apache.org/jira/browse/AXIS2-1110?page=comments#action_12433316 ] Ming Cheung commented on AXIS2-1110: Adding new permissions the policy file(s) sometimes may not be enough to resolve the privilege issues. Acutally, I am thinking of introducing a new AccessController class into the CORE module. This new AXIS2 AccessController is a class which delegates all doPrivileged calls to correspondent APIs defined in java.secuirty.AccessController class. One of the main reason for introducing this new AXIS2 AccessController Class is to improve the runtime performance when java security is not enabled. Here is a link which talks more about the usage of Java 1.5.0's doPrivileged constructs http://java.sun.com/j2se/1.5.0/docs/guide/security/doprivileged.html Java 2 Security --- Key: AXIS2-1110 URL: http://issues.apache.org/jira/browse/AXIS2-1110 Project: Apache Axis 2.0 (Axis2) Issue Type: New Feature Components: core Environment: Supporting Axis2 runs inside of an environment with Java 2 Security enabled Reporter: Ming Cheung We need a feature which can provide us fine-grained access control to grant privileges when the codes needed, and to have code operate with the minimum necessray privileges. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2-1123) do you know that
do you know that - Key: AXIS2-1123 URL: http://issues.apache.org/jira/browse/AXIS2-1123 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Components: core Affects Versions: 0.96 Environment: i just new here i don't know what can i do ?but i like apache and these day i just study the apache and to set up a apache server!!! will you help !!! Reporter: chenghui jang i like you all .like apache -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
