Re: [Axis2] Possible bug in the AxisEngine.resume() method
Hi Glen, Since TransportSender already extend the Handler interface it can be easily attached to the end of the handler chain. But MessageReceiver is a seperate interface and this does not extend Handler. Are you suggesting that the MessageReceiver should extend the Handler interface. (also this will remove the need for a MessageReceiver.receive() method since the invoke() method from the Handler interface can be directly used). (I don't know weather there is a special reason for MessageReceiver not being a Handler in the current implementation) Thank you, Camikara On 12/16/05, Glen Daniels <[EMAIL PROTECTED]> wrote: > So the end result is a single execution chain which pauses/resumes> simply by indexes, updates itself at operation dispatch, and no extra> logic to split receiving/sending.>> Sound reasonable? >> +1OK, cool. I'm more than willing to do this work next week (am onvacation as of tonight for the weekend), but assuming others are goodwith this, please feel free to commit the patch and/or the refactoring before then if you wish.--Glen
[jira] Commented: (AXIS-2272) Duplicated operation names
[ http://issues.apache.org/jira/browse/AXIS-2272?page=comments#action_12360554 ] Jason Weiss commented on AXIS-2272: --- We've run into this exact same issue on multiple projects. We've wasted more time wondering what was going on until we actually looked at the WSDL and saw the operation duplicated in the WSDL. Please fix this :-) > Duplicated operation names > -- > > Key: AXIS-2272 > URL: http://issues.apache.org/jira/browse/AXIS-2272 > Project: Apache Axis > Type: Bug > Components: WSDL processing > Versions: 1.2.1 > Environment: Server - jakarta tomcat 5.0.28, spring framework 1.2.5 > OS - Windows server 2003 > Java - java full version "1.4.2_07-b05" > Client - Macromedia flex running in MS IE 6.0 > Reporter: Alex Grivnin > Attachments: axis.zip > > Axis generates invalid WSDL - more specifically operation names appears to be > duplicated in WSDL. > This happens sporadically and I do not have a specific scenario to reproduce > it. But I'll try to describe the application flow and may be it will provide > some hint... > Our application runs on a Tomcat server 5.0.28, it uses spring framework > 1.2.5 for binding Axis beans which are exposed to the client. See wsdd > fragment at the end of the message as well as spring context. > At some point client (Macromedia flesh) requests wsdl before calling a web > service and gets an exception that fetched WSDL is not supported (as it > contains duplicated operation names). > Configuration files: > -- > --- WSDD fragment -- > >value="com.mercury.onyx.client.services.axis.SpringBeanRPCProvider"/> >value="deleteFilter,getFilter,saveUserFilter,getUserViews,getUserFilterCategories"/> > >languageSpecificType="java:com.mercury.onyx.client.services.vo.FilterCategoryVO" > qname="ns3:FilterCategoryVO" xmlns:ns3="someNamespace"/> >languageSpecificType="java:com.mercury.onyx.client.services.vo.FilterVO" > qname="ns3:FilterVO" xmlns:ns3="someNamespace"/> >languageSpecificType="java:com.mercury.onyx.client.services.vo.FilterDefinitionVO" > qname="ns3:FilterDefinitionVO" xmlns:ns3="someNamespace"/> >languageSpecificType="java:com.mercury.onyx.client.services.vo.FilterConstraintVO" > qname="ns3:FilterConstraintVO" xmlns:ns3="someNamespace"/> >languageSpecificType="java:com.mercury.onyx.client.services.vo.ViewVO" > qname="ns3:ViewVO" xmlns:ns3="someNamespace"/> >languageSpecificType="java:com.mercury.onyx.client.services.vo.AttributeVO" > qname="ns3:AttributeVO" xmlns:ns3="someNamespace"/> > > --- End of WSDD fragment -- > --- Spring bean context - >class="com.mercury.onyx.client.services.webservices.FiltersWS"> > > > > > > > > > > > --- End of Spring bean context - -- 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
[axis2] MessageContext IDs
Is there any reason why we can't make it so that every message context
has an id when its created? I'm fine with having getId() and setId() so
that the default ID can be changed but it seems to me that we never use
a message context without setting the ID. This avoids repeated code
fragments like:
if (msgctx.getMessageID() == null) {
String messageID = String.valueOf("uuid:" + UUIDGenerator.getUUID());
msgctx.setMessageID(messageID);
}
Sanjiva.
RE: Clustering Axis2
On Wed, 2005-12-14 at 14:07 -0500, Rajith Attapattu wrote: > http://wadi.codehaus.org/ > > Fankly I am no expert either, I am actually working on (discussion > stage) adding HA-JNDI to WADI. > > Jeff Geneder and Jules Gosnel are the experts and according to Jeff the > web session clustering works well with tomcat and jetty off the box. > > I can certainly look into how we can integrate WADI with Axis2 to enable > clustering. (I am on vacation next week and will have time to play > around with it if that's not too late) > > Also Jules is having a informal clustering session in ApacheCon hakethon > area now, so if one of Axis guys can meet him or Jeff they can get more > first hand information. > > Also once the ApacheCon is over I can get more support from them if I > have questions about the integration. > > Let me know if this works. +1! Sanjiva.
Re: [Axis2] Possible bug in the AxisEngine.resume() method
Hi Chamikara! > Actually what I merged was the AxisEngine.send() method (not receive() > ). Shouldn't both chains be available by the time this get called by the > MessageReceiver ? > If so merging in the begining should not be a problem. Woops, my bad - I misinterpreted the patch. Yes, you're quite right. > So the end result is a single execution chain which pauses/resumes > simply by indexes, updates itself at operation dispatch, and no extra > logic to split receiving/sending. > > Sound reasonable? > > +1 OK, cool. I'm more than willing to do this work next week (am on vacation as of tonight for the weekend), but assuming others are good with this, please feel free to commit the patch and/or the refactoring before then if you wish. --Glen
Re: [VOTE] David Blevins as Axis committer (Re: Axis 1.4 FinalBranch)
+ for David. Jaliya - Original Message - From: Thilina Gunarathne To: axis-dev@ws.apache.org Sent: Thursday, December 15, 2005 6:03 AM Subject: Re: [VOTE] David Blevins as Axis committer (Re: Axis 1.4 FinalBranch) +1 ~Thilina On 12/14/05, jayachandra <[EMAIL PROTECTED]> wrote: Here is my +1 Jaya On 12/14/05, Tom Jordahl <[EMAIL PROTECTED] > wrote: +1 to David.All help with Axis 1.x appreciated!--Tom Jordahl> -Original Message- > From: Sanjiva Weerawarana [mailto:[EMAIL PROTECTED]]> Sent: Tuesday, December 13, 2005 2:17 PM > To: [EMAIL PROTECTED] > Cc: axis-dev@ws.apache.org; dev@geronimo.apache.org> Subject: Re: [VOTE] David Blevins as Axis committer (Re: Axis 1.4 > FinalBranch)>> On Mon, 2005-12-12 at 03:41 -0500, Davanum Srinivas wrote:> > Folks,> >> > Can we please vote David as committer to take care of Axis 1.x.> > > > Here's my +1>> +1 .. welcome aboard David.>> Sanjiva.>-- -- Jaya -- "May the SourcE be with u"http://webservices.apache.org/~thilina/http://thilinag.blogspot.com/ http://www.bloglines.com/blog/Thilina
Re: [Axis2] Possible bug in the AxisEngine.resume() method
Hi Glen,
Please see my comments below.On 12/15/05, Glen Daniels <[EMAIL PROTECTED]> wrote:
Hi Chamikara:+1 and -1 to parts of this patch. :)First, I agree about merging the chains (op-specifc and global) into one- that was the intent (a single EC) from the first Axis2 meetings. Theproblem with doing it here is that I think this method might get called
before operation dispatching has occurred (so getAxisOperation() willprobably give you a null, resulting in a NPE). The way this shouldprobably work is that the act of dispatching to the AxisOperation itself
(i.e. MessageContext.setAxisOperation()) should cause the chains to bemerged/replaced. Then this portion of the code only needs to worryabout pausing/resuming a single chain.
Actually what I merged was the AxisEngine.send() method (not receive()
). Shouldn't both chains be available by the time this get called by
the MessageReceiver ?
If so merging in the begining should not be a problem.
For the receive() method, agreed :) . (actually this seems to be the
way it currently work. Dynamic chain replacing has been implemented in
the 'checkPostConditions' method of the 'DispatchPhase' class).
Along the lines of making this simpler, I don't like having resumeSend()and resumeReceive() - why should the core execution code care which
direction things are going? I believe that the correct thing to do hereis to slightly refactor the chains, and simply have the transport sender/ message receiver as Handlers on the ends of the execution chain. That
way we could remove all the extra logic of calling senders/receiversmanually, and just have them invoked automatically by executing thehandler chain (that's how Axis 1 did it too).
+1. The reason for going for two resume() methods was
the act of TransportSender and
MessageReceiver being called seperately in the send() and
receive() methods. If they are a part of the execution chain one
resume() method would do it.
So the end result is a single execution chain which pauses/resumessimply by indexes, updates itself at operation dispatch, and no extra
logic to split receiving/sending.Sound reasonable?
+1
Thanks,
Chamikara
Chamikara Jayalath wrote:> Hi All,>> There seems to be a bug in the
AxisEngine.resume() method (which was> recently added)>> Wihtin this, only the currently attached execution chain is resumed.> But AxisEngine.send() method attachs two execution chains (service
> specific and global) and invoke both. Because of this if pausing happen> in a service specific out handler, the global out handlers are ommitted> when resuming. Also resume mothod does not seem to be calling the
> MessageReceiver or TransportSender.>> I have attached a fix to this. First doing two msgContext.invoke() calls> in the send() method will not work because when resuming we don't know> weather the first or second chain we were in when pausing. So I combined
> both chains to a one ArrayList and invoked at once.>> Also since we have to call the MessageReceiver or TransportSender after> the invocation of handlers (depending on weather we paused in the send()
> method or receive() method) it seems better to have two resume methods> named resumeSend() and resumeReceive() which will call TransportSender> and MessageReceiver respectively (after invoking the execution chain).
>> Please see the attached patch.>> Thank you,> Chamikara>>> >> Index: engine/AxisEngine.java
> ===> --- engine/AxisEngine.java(revision 356796)> +++ engine/AxisEngine.java(working copy)> @@ -66,12 +66,13 @@> public void send(MessageContext msgContext) throws AxisFault {
> //find and invoke the Phases> OperationContext
operationContext = msgContext.getOperationContext();> -ArrayList executionChain = operationContext.getAxisOperation().getPhasesOutFlow();> -msgContext.setExecutionChain((ArrayList) executionChain.clone
());> +ArrayList outFlow = (ArrayList) operationContext.getAxisOperation().getPhasesOutFlow().clone();> +ArrayList globalOutFlow = (ArrayList) msgContext.getConfigurationContext().getAxisConfiguration().getGlobalOutPhases().clone();
> +> +outFlow.addAll(globalOutFlow);> +> +msgContext.setExecutionChain(outFlow);> msgContext.invoke();> -msgContext.setExecutionChain((ArrayList)msgContext.getConfigurationContext().
>
-getAxisConfiguration().getGlobalOutPhases().clone());> -msgContext.invoke();>> if (!msgContext.isPaused()) {> //write the Message to the Wire
> @@ -385,10 +386,29 @@> }>>> -public void resume(MessageContext msgctx)> +public void resumeSend(MessageContext msgctx)> throws AxisFault {>
msgctx.resume();> +> +if (!msgctx.isPaused()) {> +//write the Message to the Wire>
+TransportOutDescription
t
[jira] Commented: (AXIS-2342) Reopen issue: Character entities are escaped too aggressively
[
http://issues.apache.org/jira/browse/AXIS-2342?page=comments#action_12360513 ]
Thiago Jung Bauermann commented on AXIS-2342:
-
I am opening this issue again because it appears that the fix to this problem
was removed from the source code. From what I could tell looking at the
subversion repository, the revision 257917 restored the old, buggy code.
This is affecting me because my application must talk to a webservice which
doesn't understand XML character entities (I know, it should, but fixing the
webservice is not an option). The only way I can send non-ASCII characters is
using UTF-8 or ISO-8859-1, which is not possible with Axis.
I tested with Axis 1.2.1 and 1.3. I didn't test with the trunk version, but
looking at the code with ViewCVS, the problem is still there (class
UTF8Encoder).
> Reopen issue: Character entities are escaped too aggressively
> -
>
> Key: AXIS-2342
> URL: http://issues.apache.org/jira/browse/AXIS-2342
> Project: Apache Axis
> Type: Bug
> Components: Serialization/Deserialization
> Versions: 1.0
> Environment: Operating System: All
> Platform: All
> Reporter: Thiago Jung Bauermann
> Assignee: Axis Developers Mailing List
>
> We are using SOAP to send XML documents from client to server and back. The
> documents contain a lot of non-ASCII data. This is encoded as UTF-8 by us.
> However, when retrieved from an Axis server, Axis will escape almost all of
> our
> characters into character entities (so &#...;) This means messages become
> about
> three times as big as they have to for 'international' documents, which for
> us
> is a large performance problem. I narrowed down the problem to
> XMLUtils::xmlEncodeString
> that has the code:
> if (((int)chars[i]) > 127) {
> strBuf.append("&#");
> strBuf.append((int)chars[i]);
> strBuf.append(";");
> This seems unnecessary to me, as Axis will send all messages in UTF-8 anyway,
> for which no encoding is necessary (and should encoding be configurable, I
> feel
> this should be escaped elsewhere).
> Is there any reason for this code, I commented it out and it seemed to have
> no
> adverse effect on our application (apart from reduced network traffic)?
> Tested with 1.0, also looked up in the sources of 1.1-rc2.
--
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
[jira] Created: (AXIS-2342) Reopen issue: Character entities are escaped too aggressively
Reopen issue: Character entities are escaped too aggressively
-
Key: AXIS-2342
URL: http://issues.apache.org/jira/browse/AXIS-2342
Project: Apache Axis
Type: Bug
Components: Serialization/Deserialization
Versions: 1.0
Environment: Operating System: All
Platform: All
Reporter: Thiago Jung Bauermann
Assigned to: Axis Developers Mailing List
We are using SOAP to send XML documents from client to server and back. The
documents contain a lot of non-ASCII data. This is encoded as UTF-8 by us.
However, when retrieved from an Axis server, Axis will escape almost all of our
characters into character entities (so &#...;) This means messages become about
three times as big as they have to for 'international' documents, which for us
is a large performance problem. I narrowed down the problem to
XMLUtils::xmlEncodeString
that has the code:
if (((int)chars[i]) > 127) {
strBuf.append("&#");
strBuf.append((int)chars[i]);
strBuf.append(";");
This seems unnecessary to me, as Axis will send all messages in UTF-8 anyway,
for which no encoding is necessary (and should encoding be configurable, I feel
this should be escaped elsewhere).
Is there any reason for this code, I commented it out and it seemed to have no
adverse effect on our application (apart from reduced network traffic)?
Tested with 1.0, also looked up in the sources of 1.1-rc2.
--
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
Re: [Axis2] Possible bug in the AxisEngine.resume() method
Hi Chamikara:
+1 and -1 to parts of this patch. :)
First, I agree about merging the chains (op-specifc and global) into one
- that was the intent (a single EC) from the first Axis2 meetings. The
problem with doing it here is that I think this method might get called
before operation dispatching has occurred (so getAxisOperation() will
probably give you a null, resulting in a NPE). The way this should
probably work is that the act of dispatching to the AxisOperation itself
(i.e. MessageContext.setAxisOperation()) should cause the chains to be
merged/replaced. Then this portion of the code only needs to worry
about pausing/resuming a single chain.
Along the lines of making this simpler, I don't like having resumeSend()
and resumeReceive() - why should the core execution code care which
direction things are going? I believe that the correct thing to do here
is to slightly refactor the chains, and simply have the transport sender
/ message receiver as Handlers on the ends of the execution chain. That
way we could remove all the extra logic of calling senders/receivers
manually, and just have them invoked automatically by executing the
handler chain (that's how Axis 1 did it too).
So the end result is a single execution chain which pauses/resumes
simply by indexes, updates itself at operation dispatch, and no extra
logic to split receiving/sending.
Sound reasonable?
--Glen
Chamikara Jayalath wrote:
> Hi All,
>
> There seems to be a bug in the AxisEngine.resume() method (which was
> recently added)
>
> Wihtin this, only the currently attached execution chain is resumed.
> But AxisEngine.send() method attachs two execution chains (service
> specific and global) and invoke both. Because of this if pausing happen
> in a service specific out handler, the global out handlers are ommitted
> when resuming. Also resume mothod does not seem to be calling the
> MessageReceiver or TransportSender.
>
> I have attached a fix to this. First doing two msgContext.invoke() calls
> in the send() method will not work because when resuming we don't know
> weather the first or second chain we were in when pausing. So I combined
> both chains to a one ArrayList and invoked at once.
>
> Also since we have to call the MessageReceiver or TransportSender after
> the invocation of handlers (depending on weather we paused in the send()
> method or receive() method) it seems better to have two resume methods
> named resumeSend() and resumeReceive() which will call TransportSender
> and MessageReceiver respectively (after invoking the execution chain).
>
> Please see the attached patch.
>
> Thank you,
> Chamikara
>
>
>
>
> Index: engine/AxisEngine.java
> ===
> --- engine/AxisEngine.java(revision 356796)
> +++ engine/AxisEngine.java(working copy)
> @@ -66,12 +66,13 @@
> public void send(MessageContext msgContext) throws AxisFault {
> //find and invoke the Phases
> OperationContext operationContext = msgContext.getOperationContext();
> -ArrayList executionChain =
> operationContext.getAxisOperation().getPhasesOutFlow();
> -msgContext.setExecutionChain((ArrayList) executionChain.clone());
> +ArrayList outFlow = (ArrayList)
> operationContext.getAxisOperation().getPhasesOutFlow().clone();
> +ArrayList globalOutFlow = (ArrayList)
> msgContext.getConfigurationContext().getAxisConfiguration().getGlobalOutPhases().clone();
> +
> +outFlow.addAll(globalOutFlow);
> +
> +msgContext.setExecutionChain(outFlow);
> msgContext.invoke();
> -
> msgContext.setExecutionChain((ArrayList)msgContext.getConfigurationContext().
> -getAxisConfiguration().getGlobalOutPhases().clone());
> -msgContext.invoke();
>
> if (!msgContext.isPaused()) {
> //write the Message to the Wire
> @@ -385,10 +386,29 @@
> }
>
>
> -public void resume(MessageContext msgctx)
> +public void resumeSend(MessageContext msgctx)
> throws AxisFault {
> msgctx.resume();
> +
> +if (!msgctx.isPaused()) {
> +//write the Message to the Wire
> +TransportOutDescription transportOut = msgctx.getTransportOut();
> +TransportSender sender = transportOut.getSender();
> +sender.invoke(msgctx);
> +}
> }
> +
> +public void resumeReceive(MessageContext msgctx)
> + throws AxisFault {
> + msgctx.resume();
> +
> +if (msgctx.isServerSide() && !msgctx.isPaused()) {
> +// invoke the Message Receivers
> +checkMustUnderstand(msgctx);
> +MessageReceiver receiver =
> msgctx.getAxisOperation().getMessageReceiver();
> +receiver.receive(msgctx);
> +}
> +}
>
> private String getSenderFaultCode(St
RE: Bug in beandeserializer??
Title: Bug in beandeserializer??
Hi Everone,
It seems like either noone know what is
going on here or noone wants to offer help. I really think this is a bug, but
don't know much about it to figure it out. Can anyone please help me with
this???
Thanks,
Parikh, Pratik | Software
Engineer | Cerner Corporation | (1)-816-201-1298
| [EMAIL PROTECTED] | www.cerner.com
From: Parikh,Pratik
[mailto:[EMAIL PROTECTED] Sent: Wednesday, December 14, 2005
10:23 AMTo: axis-user@ws.apache.orgSubject: RE: Bug in
beandeserializer??
Can someone please look at this??? I need to resolve
it.
Thanks,
Parikh, Pratik | Software
Engineer | Cerner Corporation | (1)-816-201-1298
| [EMAIL PROTECTED] | www.cerner.com
From: Parikh,Pratik
[mailto:[EMAIL PROTECTED] Sent: Tuesday, December 13, 2005
6:55 PMTo: axis-user@ws.apache.orgSubject: Bug in
beandeserializer??
Hi Everyone,
I have a case where the
generated code is that behaving right with case sensitivity. My element name is
"EmptyName" and the generate code is something like this:
elemField
= new org.apache.axis.description.ElementDesc();
elemField.setFieldName("emptyName"); elemField.setXmlName(new
javax.xml.namespace.QName("urn:person-org", "EmptyName"));
elemField.setXmlType(new javax.xml.namespace.QName("urn:person-org",
"PersonOrg.EmptyName"));
elemField.setNillable(false);
typeDesc.addFieldDesc(elemField);
The schema is as following
http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:person-org" elementFormDefault="qualified"
xmlns:porg="urn:person-org" xmlns="urn:person-org">
soapenv:Server.userExceptionorg.xml.sax.SAXException:
Invalid element in org.person.PersonOrg -
EmptyNamehttp://xml.apache.org/axis/">LPP010755
When I debugged thought it is erroring out on
BeanDeserilizer line 259. Please help I need to get this working by tomorrow
morning??? I think this is a bug and if someone can fix it for me then it will
be nice???
Thanks, Parikh, Pratik | Software Engineer | Cerner Corporation | (1)-816-201-1298 | [EMAIL PROTECTED] | www.cerner.com
CONFIDENTIALITY NOTICEThis
message and any included attachmentsare from Cerner Corporation and
are intendedonly for the addressee. The informationcontained in
this message is confidential andmay constitute inside or non-public
informationunder international, federal, or statesecurities laws.
Unauthorized forwarding,printing, copying, distribution, or use of
suchinformation is strictly prohibited and may beunlawful. If you
are not the addressee, pleasepromptly delete this message and notify
thesender of the delivery error by e-mail or youmay call Cerner's
corporate offices in KansasCity, Missouri, U.S.A at (+1)
(816)221-1024.
--
Re: [VOTE] David Blevins as Axis committer (Re: Axis 1.4 FinalBranch)
+1 ~Thilina On 12/14/05, jayachandra <[EMAIL PROTECTED]> wrote: Here is my +1 Jaya On 12/14/05, Tom Jordahl <[EMAIL PROTECTED] > wrote: +1 to David.All help with Axis 1.x appreciated!--Tom Jordahl> -Original Message- > From: Sanjiva Weerawarana [mailto:[EMAIL PROTECTED]]> Sent: Tuesday, December 13, 2005 2:17 PM > To: [EMAIL PROTECTED] > Cc: axis-dev@ws.apache.org; dev@geronimo.apache.org> Subject: Re: [VOTE] David Blevins as Axis committer (Re: Axis 1.4 > FinalBranch)>> On Mon, 2005-12-12 at 03:41 -0500, Davanum Srinivas wrote:> > Folks,> >> > Can we please vote David as committer to take care of Axis 1.x.> > > > Here's my +1>> +1 .. welcome aboard David.>> Sanjiva.>-- -- Jaya -- "May the SourcE be with u"http://webservices.apache.org/~thilina/http://thilinag.blogspot.com/ http://www.bloglines.com/blog/Thilina
[jira] Created: (AXIS-2341) Error in SOAP message when using 2D-Arrays
Error in SOAP message when using 2D-Arrays
---
Key: AXIS-2341
URL: http://issues.apache.org/jira/browse/AXIS-2341
Project: Apache Axis
Type: Bug
Components: Serialization/Deserialization
Versions: 1.3
Environment: Windows Server 2003, Java 1.5.0_02
Reporter: Stian Lassemo
I have generated client files from WSDL using Axis 1.3.
One of the WebService Methods require a 2D-Array as input. Like this:
LocalizedFieldCarrier[][] adr = new LocalizedFieldCarrier[3][2];
adr[0][0] = new LocalizedFieldCarrier("StreetAddress1", "", "",
"SR_AL_STREET", 42);
adr[1][0] = new LocalizedFieldCarrier("PostalAddress1", "P.O.Box 1265",
"", "SR_AL_POSTAL", 42);
adr[2][0] = new LocalizedFieldCarrier("PostalZipcode", "1234", "",
"SR_AL_POSTCODECITY", 10);
adr[3][0] = new LocalizedFieldCarrier("PostalCity", "City", "", "", 30);
This generates the following SOAP message element:
StreetAddress1
SR_AL_STREET
42
PostalAddress1
P.O.Box 1265
SR_AL_POSTAL
42
PostalZipcode
1234
SR_AL_POSTCODECITY
10
PostalCity
City
30
The first address element differ from the rest, it seems like the first element
uses the name of it's parent, ArrayOfLocalizedFieldCarrier. The next elements
uses the correct element name, LocalizedFieldCarrier.
This generates an error when contacting the service.
--
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
