Re: only top-level element has namespace

[Anne Thomas Manes]

Ron, the schema for this document instance:

  
    
  

Would be described thus:

  
  xmlns="" >
    
   
 
   
 
    
 
   

In this definition, "bar" is defined as a local element (defined within
another structure rather than defined as a direct child of the
 element), and therefore is by default in no namespace
(It is not part of "urn:foo". If you want to make it part of the
targetNamespace, then you must add elementFormDefault="qualified" to
the schema definition, e.g., 

  

  xmlns="" 
  elementFormDefault="qualified">

    

   

 

   

 

    

 

   

In this instance:

  
    
       
    
  

There is no ambiguity. "foo" is in "urn:foo"; "snafu" is in
"urn:snafu"; and "bar" is in no namespace. In terms of validation, the
schema for "foo" must indicate that "snafu" is an expected child; and
the schema for "snafu" must indicate that "bar" is an expected child. 

AnneOn 11/3/05, Ron Reynolds <[EMAIL PROTECTED]> wrote:
that raises a schema question, since it seems that this:  only makes sense if you combine it with the schema for the namespace "urn:foo"
and you find that it's elementFormDefault="unqualified" and thus bar is stillin "urn:foo" (and not really in no namespace at all).but, what if you had 2 schemas and this XML:
     and the schema for "urn:snafu" was also elementFormDefault="unqualified" and
also defined an element ?  you would have to specify the namespace onbar to clarify, despite the schema's elementFormDefault or you would havean ambiguity, no?  does elementFormDefault only apply when the parent of the
element is in the same namespace?(hope this isn't too off-topic for the axis-user@ list) :)ron.> Axis sets the default namespace to null because your schema defines the> child elements as unqualified. If it didn't set the default namespace to
> null, then the message would not match the schema.>> If you add elementFormDefault="qualified" to your schema element, then the> child elements will be defined as qualified.>
> Anne>> On 11/3/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: I'm hoping that Anne Manes or someone more knowledgable will step forward
>> on this one, but I've seen similar questions come up on this list over the>> past few months and I wonder if the behavior you're seeing is because of>> the default "unqualified" setting that you have in your schema. See this
>> post from Anne, where she gives an example of how this might work: http://marc.theaimsgroup.com/?l=axis-user&m=112241677227703&w=2
 Here's another response from Anne, to a question that's the opposite of>> yours--how to suppress the namespaces being added to every element!>> 
http://marc.theaimsgroup.com/?l=axis-user&m=111823412914728&w=2 Hope this helps-- Meghan _>> Meghan Pietila
>> Java Middleware Architect>> Sales & Service Management Program>> US Bank>> Gold 4>> (651) 205-0904>> (651) 271-2815 cell>> 
[EMAIL PROTECTED]>> "Ron Reynolds">> <[EMAIL PROTECTED] To: axis-user@ws.apache.org
>> com> cc:>> Subject: only top-level element has namespace>> 11/02/2005 06:18>> PM>> Please respond to>> axis-user
>> i hate to ask a duplicate question but 5 minuets digging in the list>> archives was leading nowhere.>> my question is, what's causing this 'xmlns=""' to be added and how do i
>> prevent it? (my service is document-literal) >> amgen.com/freezer/data
>> ">>> >> >> ...
 same thing's happening on the request side as well - >> amgen.com/freezer/data>> ">>> FooTest
>> Volume>> >> 1>> 2
>> ... is it a WSDL issue? i import the type XSD thus:>> amgen.com/freezer<
http://amgen.com/freezer>>> ">> xmlns:tns = "urn:amgen.com/freezer "
>> xmlns:data = "" href="http://amgen.com/freezer/data">amgen.com/freezer/data ">> xmlns:soap = "
http://schemas.xmlsoap.org/wsdl/soap/>> ">> xmlns:xsd = "http://www.w3.org/2001/XMLSchema">> xmlns:wsdl = "
http://schemas.xmlsoap.org/wsdl/">>> amgen.com/freezer/data>> ">>> amgen.com/freezer/data>> ">>> amgen.com/freezer/data>> ">> schemaLocation="freezer-data.xsd"/>>> ...>> >> type="data:TFindVialsByAttributesRequest"/>
>> >> type="data:TFindVialsByAttributesResponse"/>>> >> >> ...
>> >> >> element="data:findVialsByAttributesRequest"/>>> 
>> >> >> element="data:findVialsByAttributesResponse"/>>> 
>> ... i noticed the XSD doesn't explicitly call out qualified elements:>> >> targetNamespace="urn:amgen.com/freezer/data
>> ">> xmlns:data ="" href="http://amgen.com/freezer/data">amgen.com/freezer/data <
http://amgen.com/freezer/data>">> xmlns:xsd = "http://www.w3.org/2001/XMLSchema">>> 
>> >> ... could that be a problem? it still doesn't make sense wh

Re: is there an advantage of using axis on client side instead of jax rpc?

[Anne Thomas Manes]

One note: the next release of JAX-RPC (which is currently in public
review) is so different from the last release that Sun changed its name
to JAX-WS. This new version relies on Java 5 and makes extensive use of
metadata annotations. The programming model is completely different.

Given that JAX-RPC will be deprecated soon, I don't think it matters
which client you use in terms of long-term protection -- all current
implementations will be obsolete. But as Arun says, the Axis team is
building much more extensive support for the advanced WS-* specs. 

AnneOn 11/4/05, Soactive Inc <[EMAIL PROTECTED]> wrote:
In general, both API currently have comparable functionality on the
client side. Given the amount of Web Services-related activities and
APIs being developed (broadly) as part of the the Axis Project
(WS-Security -> WSS4J, WS-RM -> Sandesha, etc.) I would like to
stick with Axis and the Apache WS API for the foreseeable future. 

That said, these are all implementations of standards and as time goes
on they will become more and more interchangeable in case you want to
switch the underlying implementations in your architecture.

-ArunOn 11/4/05, SOA Work <
[EMAIL PROTECTED]> wrote:

Hi,I`m wondering which are the advantages of using axis on client side instead of the core jax rpc?I think no real dynamic invocation is easily possible on both and jax rpc can generate java classes for a wsdl file too. 
thx in advanceDominik

Verschicken Sie romantische, coole und witzige Bilder per SMS!   Jetzt bei WEB.DE FreeMail: 

http://f.web.de/?mc=021193  

Re: AXIS reaponse on array and duplicate attributes

[Anne Thomas Manes]

Chris said, 

"As far as I can tell, Schema 1999 is deprecated and 'bad'."
Yes. XML Schema 1999 was one of the working drafts of the XML Schema
working group. Most SOAP stacks do not support this version. The 2001
version is the only version of XML Schema v1.0 that was ratified. And
it's the only one you should use.

Anne

RE: StAX API (http://java.sun.com/webservices/docs/1.6/tutorial/doc/SJSXP3.html) and AXIS 2.0

[Parikh,Pratik]

Hi Ajith,
 
    I fall under issue second, so I assume, 
I am going to try to generate this using cmdline ant. I think that should work 
for me, I will update you on that.
 
   Is there a example of migrating client 
code manually and I am using ws-addressing. I think this is supported directly 
by Axis2. 
 
Thanks,
Parikh, 
Pratik


From: Ajith Ranabahu 
[mailto:[EMAIL PROTECTED] Sent: Saturday, November 05, 2005 
3:31 PMTo: axis-user@ws.apache.orgSubject: Re: StAX API 
(http://java.sun.com/webservices/docs/1.6/tutorial/doc/SJSXP3.html) and AXIS 
2.0
Hi Pratik,Are you using the latest code ? This particular problem 
is known to arise in two cases.1. When the used DOM parser is not 
namespace aware2. Inside the Eclipse environment (even when the parser is 
namespace aware)Issue 1 is already fixed and should not be present in 
the latest code. The second issue however is still there and we've not being 
able to find a solution.Also a word about migration. Even though the 
Axis1 server side code is transferabble to the Axis2 environment, right now 
there is no way to convert client code! (Apart from regenerating the client from 
the WSDL). We are looking into the possibility of introducing a tool that helps 
in migration but it may not be soon, most probably post 1.0
On 11/6/05, Parikh,Pratik <[EMAIL PROTECTED] > 
wrote:

  I am 
  trying to use Axis2 migrating from Axis1.3. And am trying to generate code, 
  but i get follwoing. It seems like the way axis is using this might need to be 
  modified. I don't know if this is a defect or what, can someone more 
  knowledgeable with code look into this. 
   
  build.xml:24: 
  org.apache.axis2.wsdl.codegen.CodeGenerationException: 
  java.lang.RuntimeException: org.apache.xmlbeans.XmlException: 
  Thread main: The 0th supplied input is not a schema document: its type is N=
   
  Reference 
  Thread
  http://mail-archives.apache.org/mod_mbox/xml-xmlbeans-user/200407.mbox/[EMAIL PROTECTED]
   
  Thanks,
  Parikh, Pratik 
  
  From: Jayaraman, Venkatesh [mailto:[EMAIL PROTECTED]] 
  Sent: Saturday, November 05, 2005 1:17 PMTo: Jayaraman, 
  Venkatesh; axis-user@ws.apache.orgSubject: RE: StAX API (http://java.sun.com/webservices/docs/1.6/tutorial/doc/SJSXP3.html) 
  and AXIS 2.0
  
  
  
  How much speed we 
  will gain in Axis 2.0 over (Axis 1.2 and Axis 1.3) ?
  Also In Axis 1.2 RC3, 
  is parser reuse is turned on by default to increase the 
  performance?
   
  -Venky
   
   
   
  
  
  
  
  From: 
  Jayaraman, Venkatesh Sent: 
  Saturday, November 05, 2005 11:14 AMTo: 'axis-user@ws.apache.org 
  'Subject: StAX API (http://java.sun.com/webservices/docs/1.6/tutorial/doc/SJSXP3.html) 
  and AXIS 2.0
   
   
  
  What is new in Axis 2.0 
  version?
  
Speed - Axis2 is based on StAX 
API(http://java.sun.com/webservices/docs/1.6/tutorial/doc/SJSXP3.html 
), which gives greater speed than SAX event base parsing that has been used 
in Axis1.2
Stability - Axis2 has fixed 
phases and for extensions an area of user defined phases. This allows far 
more stability and flexibility than Axis1.x.
Transport framework - Simple 
abstraction designing of transports (i.e., senders and listeners for SOAP 
over various protocols such as SMTP, etc), allow far more flexibility and 
the core of the engine is completely 
transport-independent.
WSDL Support - Axis2 supports 
version 1.1 and 2.0, which allow creating stubs and skeletons, to manipulate 
web service arena.
Component - Oriented 
Architecture - This is merely through archives (.mar and .aar) . Easily 
reusable components such as Handlers, Modules allow patterns processing for 
your applications, or to distribute to partners. Axis2 more concern on the 
"Module" concept rather Handler concept. Modules contain handlers that have 
been ordered through phase rules. which being ordered to specific 
service(s).
  Why stAX (not SAX) 
  parsing?
  
The Streaming API for XML (StAX) 
allows not only parsing of XML documents but also writing XML documents to 
an output stream. 
Until recently, programmers had 
only two choices when creating XML documents programmatically. Their first 
option was to directly write serialized XML content to the output stream, 
and the second was to use DOM.
Both options have severe 
drawbacks. In the first case, the programmer is fully responsible for 
ensuring that the resulting document is well formed. The programmer must 
take care of details such as matching start and end tags or the escaping of 
special characters, such as the less than sign (<) and the ampersand 
(&), in character content. This can make the implementation of programs 
tedious and error prone. DOM, on the other hand, frees the programmer from 
this burden but introduces considerable overhead: The complete document must 
first be constructed as a node tree in memory before it can be

Re: StAX API (http://java.sun.com/webservices/docs/1.6/tutorial/doc/SJSXP3.html) and AXIS 2.0

[Ajith Ranabahu]

Hi Pratik,
Are you using the latest code ? This particular problem is known to arise in two cases.

1. When the used DOM parser is not namespace aware
2. Inside the Eclipse environment (even when the parser is namespace aware)

Issue 1 is already fixed and should not be present in the latest code.
The second issue however is still there and we've not being able to
find a solution.

Also a word about migration. Even though the Axis1 server side code is
transferabble to the Axis2 environment, right now there is no way to
convert client code! (Apart from regenerating the client from the
WSDL). We are looking into the possibility of introducing a tool that
helps in migration but it may not be soon, most probably post 1.0On 11/6/05, Parikh,Pratik <[EMAIL PROTECTED]
> wrote:






I am trying to use Axis2 migrating from Axis1.3. And am

trying to generate code, but i get follwoing. It seems like the way axis is

using this might need to be modified. I don't know if this is a defect or what,

can someone more knowledgeable with code look into this. 
 
build.xml:24: org.apache.axis2.wsdl.codegen.CodeGenerationException:

java.lang.RuntimeException: org.apache.xmlbeans.XmlException:

Thread main: The 0th supplied input is not a schema document: its type

is N=
 
Reference Thread

http://mail-archives.apache.org/mod_mbox/xml-xmlbeans-user/200407.mbox/[EMAIL PROTECTED]
 
Thanks,
Parikh, Pratik

From: Jayaraman, Venkatesh

[mailto:[EMAIL PROTECTED]] Sent: Saturday, November 05, 2005 1:17

PMTo: Jayaraman, Venkatesh;

axis-user@ws.apache.orgSubject: RE: StAX API

(http://java.sun.com/webservices/docs/1.6/tutorial/doc/SJSXP3.html) and AXIS

2.0


How much speed we will

gain in Axis 2.0 over (Axis 1.2 and Axis 1.3) ?
Also In Axis 1.2 RC3,

is parser reuse is turned on by default to increase the

performance?
 
-Venky
 
 
 




From:

Jayaraman, Venkatesh Sent:

Saturday, November 05, 2005 11:14 AMTo: 'axis-user@ws.apache.org
'Subject: StAX API

(http://java.sun.com/webservices/docs/1.6/tutorial/doc/SJSXP3.html) and AXIS

2.0
 
 

What is new in Axis 2.0

version?

  Speed - Axis2 is based on StAX

  API(http://java.sun.com/webservices/docs/1.6/tutorial/doc/SJSXP3.html
),

  which gives greater speed than SAX event base parsing that has been used in

  Axis1.2
  Stability - Axis2 has fixed phases

  and for extensions an area of user defined phases. This allows far more

  stability and flexibility than Axis1.x.
  Transport framework - Simple

  abstraction designing of transports (i.e., senders and listeners for SOAP over

  various protocols such as SMTP, etc), allow far more flexibility and the core

  of the engine is completely transport-independent.
  WSDL Support - Axis2 supports

  version 1.1 and 2.0, which allow creating stubs and skeletons, to manipulate

  web service arena.
  Component - Oriented Architecture

  - This is merely through archives (.mar and .aar) . Easily reusable components

  such as Handlers, Modules allow patterns processing for your applications, or

  to distribute to partners. Axis2 more concern on the "Module" concept rather

  Handler concept. Modules contain handlers that have been ordered through phase

  rules. which being ordered to specific service(s).
Why stAX (not SAX)

parsing?

  The Streaming API for XML (StAX)

  allows not only parsing of XML documents but also writing XML documents to an

  output stream. 
  Until recently, programmers had

  only two choices when creating XML documents programmatically. Their first

  option was to directly write serialized XML content to the output stream, and

  the second was to use DOM.
  Both options have severe

  drawbacks. In the first case, the programmer is fully responsible for ensuring

  that the resulting document is well formed. The programmer must take care of

  details such as matching start and end tags or the escaping of special

  characters, such as the less than sign (<) and the ampersand (&), in

  character content. This can make the implementation of programs tedious and

  error prone. DOM, on the other hand, frees the programmer from this burden but

  introduces considerable overhead: The complete document must first be

  constructed as a node tree in memory before it can be serialized to an output

  stream.
  The Streaming API for XML (StAX)

  completely changes this. Unlike the Simple API for XML (SAX), StAX offers an

  API for writing XML documents. To be precise, it offers two APIs: a low-level,

  cursor-based API (XMLStreamWriter
), and a

  higher-level, event-based API (XMLEventWriter
). While

  the cursor-based API is best used in data binding scenarios (for example,

  creating a document from application data), the event-based API is typically

  used in pipelining scenarios where a new document is constructed from the data

  of input documents.
  StAX does not guarantee

  well-formed documents. It is still possible to produce a document that

  violates the XML recommendation, such as a doc

RE: StAX API (http://java.sun.com/webservices/docs/1.6/tutorial/doc/SJSXP3.html) and AXIS 2.0

[Parikh,Pratik]

I am trying to use Axis2 migrating from Axis1.3. And am
trying to generate code, but i get follwoing. It seems like the way axis is
using this might need to be modified. I don't know if this is a defect or what,
can someone more knowledgeable with code look into this. 
 
build.xml:24: org.apache.axis2.wsdl.codegen.CodeGenerationException:
java.lang.RuntimeException: org.apache.xmlbeans.XmlException:
Thread main: The 0th supplied input is not a schema document: its type
is N=
 
Reference Thread
http://mail-archives.apache.org/mod_mbox/xml-xmlbeans-user/200407.mbox/[EMAIL PROTECTED]
 
Thanks,
Parikh, Pratik

From: Jayaraman, Venkatesh
[mailto:[EMAIL PROTECTED] Sent: Saturday, November 05, 2005 1:17
PMTo: Jayaraman, Venkatesh;
axis-user@ws.apache.orgSubject: RE: StAX API
(http://java.sun.com/webservices/docs/1.6/tutorial/doc/SJSXP3.html) and AXIS
2.0


How much speed we will
gain in Axis 2.0 over (Axis 1.2 and Axis 1.3) ?
Also In Axis 1.2 RC3,
is parser reuse is turned on by default to increase the
performance?
 
-Venky
 
 
 




From:
Jayaraman, Venkatesh Sent:
Saturday, November 05, 2005 11:14 AMTo: 'axis-user@ws.apache.org'Subject: StAX API
(http://java.sun.com/webservices/docs/1.6/tutorial/doc/SJSXP3.html) and AXIS
2.0
 
 

What is new in Axis 2.0
version?

  Speed - Axis2 is based on StAX
  API(http://java.sun.com/webservices/docs/1.6/tutorial/doc/SJSXP3.html),
  which gives greater speed than SAX event base parsing that has been used in
  Axis1.2
  Stability - Axis2 has fixed phases
  and for extensions an area of user defined phases. This allows far more
  stability and flexibility than Axis1.x.
  Transport framework - Simple
  abstraction designing of transports (i.e., senders and listeners for SOAP over
  various protocols such as SMTP, etc), allow far more flexibility and the core
  of the engine is completely transport-independent.
  WSDL Support - Axis2 supports
  version 1.1 and 2.0, which allow creating stubs and skeletons, to manipulate
  web service arena.
  Component - Oriented Architecture
  - This is merely through archives (.mar and .aar) . Easily reusable components
  such as Handlers, Modules allow patterns processing for your applications, or
  to distribute to partners. Axis2 more concern on the "Module" concept rather
  Handler concept. Modules contain handlers that have been ordered through phase
  rules. which being ordered to specific service(s).
Why stAX (not SAX)
parsing?

  The Streaming API for XML (StAX)
  allows not only parsing of XML documents but also writing XML documents to an
  output stream. 
  Until recently, programmers had
  only two choices when creating XML documents programmatically. Their first
  option was to directly write serialized XML content to the output stream, and
  the second was to use DOM.
  Both options have severe
  drawbacks. In the first case, the programmer is fully responsible for ensuring
  that the resulting document is well formed. The programmer must take care of
  details such as matching start and end tags or the escaping of special
  characters, such as the less than sign (<) and the ampersand (&), in
  character content. This can make the implementation of programs tedious and
  error prone. DOM, on the other hand, frees the programmer from this burden but
  introduces considerable overhead: The complete document must first be
  constructed as a node tree in memory before it can be serialized to an output
  stream.
  The Streaming API for XML (StAX)
  completely changes this. Unlike the Simple API for XML (SAX), StAX offers an
  API for writing XML documents. To be precise, it offers two APIs: a low-level,
  cursor-based API (XMLStreamWriter), and a
  higher-level, event-based API (XMLEventWriter). While
  the cursor-based API is best used in data binding scenarios (for example,
  creating a document from application data), the event-based API is typically
  used in pipelining scenarios where a new document is constructed from the data
  of input documents.
  StAX does not guarantee
  well-formed documents. It is still possible to produce a document that
  violates the XML recommendation, such as a document with several root elements
  or several XML prologues, or tag and attribute names containing whitespace or
  characters not supported by XML. StAX implementations may check these issues
  but they are not required to do so (the reference implementation doesn't).
  Nevertheless, the StAX XMLStreamWriter is a big
  improvement over outputting raw XML data, and it does this at a fraction of
  the cost of using DOM.
--Venky

CONFIDENTIALITY NOTICE

This message and any included attachments
are from Cerner Corporation and are intended
only for the addressee. The information
contained in this message is confidential and
may constitute inside or non-public information
under international, federal, or state
securities laws. Unauthorized forwarding,
printing, copying, distrib

RE: StAX API (http://java.sun.com/webservices/docs/1.6/tutorial/doc/SJSXP3.html) and AXIS 2.0

[Jayaraman, Venkatesh]

How much speed we will gain in Axis 2.0
over (Axis 1.2 and Axis 1.3) ?

Also In Axis 1.2 RC3, is parser reuse is
turned on by default to increase the performance?

 

-Venky

 

 

 









From: Jayaraman,
Venkatesh 
Sent: Saturday, November 05, 2005
11:14 AM
To: 'axis-user@ws.apache.org'
Subject: StAX API
(http://java.sun.com/webservices/docs/1.6/tutorial/doc/SJSXP3.html) and AXIS
2.0



 

 



What
is new in Axis 2.0 version?



Speed
- Axis2 is based on StAX API(http://java.sun.com/webservices/docs/1.6/tutorial/doc/SJSXP3.html),
which gives greater speed than SAX event base parsing that has been used in
Axis1.2

Stability
- Axis2 has fixed phases and for extensions an area of user defined phases.
This allows far more stability and flexibility than Axis1.x.

Transport
framework - Simple abstraction designing of transports (i.e., senders and
listeners for SOAP over various protocols such as SMTP, etc), allow far more
flexibility and the core of the engine is completely transport-independent.

WSDL
Support - Axis2 supports version 1.1 and 2.0, which allow creating stubs and
skeletons, to manipulate web service arena.

Component
- Oriented Architecture - This is merely through archives (.mar and .aar) .
Easily reusable components such as Handlers, Modules allow patterns processing
for your applications, or to distribute to partners. Axis2 more concern on the
"Module" concept rather Handler concept. Modules contain handlers
that have been ordered through phase rules. which being ordered to specific
service(s).



Why stAX (not SAX) parsing?



The
Streaming API for XML (StAX) allows not only parsing of XML documents but also
writing XML documents to an output stream. 

Until
recently, programmers had only two choices when creating XML documents
programmatically. Their first option was to directly write serialized XML
content to the output stream, and the second was to use DOM.

Both
options have severe drawbacks. In the first case, the programmer is fully
responsible for ensuring that the resulting document is well formed. The
programmer must take care of details such as matching start and end tags or the
escaping of special characters, such as the less than sign (<) and the ampersand
(&), in character content. This can make the implementation of programs
tedious and error prone. DOM, on the other hand, frees the programmer from this
burden but introduces considerable overhead: The complete document must first
be constructed as a node tree in memory before it can be serialized to an
output stream.

The
Streaming API for XML (StAX) completely changes this. Unlike the Simple API for
XML (SAX), StAX offers an API for writing XML documents. To be precise, it
offers two APIs: a low-level, cursor-based API (XMLStreamWriter), and a
higher-level, event-based API (XMLEventWriter). While the
cursor-based API is best used in data binding scenarios (for example, creating
a document from application data), the event-based API is typically used in
pipelining scenarios where a new document is constructed from the data of input
documents.

StAX
does not guarantee well-formed documents. It is still possible to produce a
document that violates the XML recommendation, such as a document with several
root elements or several XML prologues, or tag and attribute names containing
whitespace or characters not supported by XML. StAX implementations may check
these issues but they are not required to do so (the reference implementation
doesn't). Nevertheless, the StAX XMLStreamWriter is a big
improvement over outputting raw XML data, and it does this at a fraction of the
cost of using DOM.



--Venky

StAX API (http://java.sun.com/webservices/docs/1.6/tutorial/doc/SJSXP3.html) and AXIS 2.0

[Jayaraman, Venkatesh]

 



What
is new in Axis 2.0 version?



Speed
- Axis2 is based on StAX API(http://java.sun.com/webservices/docs/1.6/tutorial/doc/SJSXP3.html),
which gives greater speed than SAX event base parsing that has been used in
Axis1.2

Stability
- Axis2 has fixed phases and for extensions an area of user defined phases.
This allows far more stability and flexibility than Axis1.x.

Transport
framework - Simple abstraction designing of transports (i.e., senders and
listeners for SOAP over various protocols such as SMTP, etc), allow far more
flexibility and the core of the engine is completely transport-independent.

WSDL
Support - Axis2 supports version 1.1 and 2.0, which allow creating stubs and
skeletons, to manipulate web service arena.

Component
- Oriented Architecture - This is merely through archives (.mar and .aar) .
Easily reusable components such as Handlers, Modules allow patterns processing
for your applications, or to distribute to partners. Axis2 more concern on the
"Module" concept rather Handler concept. Modules contain handlers
that have been ordered through phase rules. which being ordered to specific
service(s).



Why stAX (not SAX) parsing?



The
Streaming API for XML (StAX) allows not only parsing of XML documents but also
writing XML documents to an output stream. 

Until
recently, programmers had only two choices when creating XML documents
programmatically. Their first option was to directly write serialized XML
content to the output stream, and the second was to use DOM.

Both
options have severe drawbacks. In the first case, the programmer is fully
responsible for ensuring that the resulting document is well formed. The
programmer must take care of details such as matching start and end tags or the
escaping of special characters, such as the less than sign (<) and the
ampersand (&), in character content. This can make the implementation of
programs tedious and error prone. DOM, on the other hand, frees the programmer
from this burden but introduces considerable overhead: The complete document
must first be constructed as a node tree in memory before it can be serialized
to an output stream.

The
Streaming API for XML (StAX) completely changes this. Unlike the Simple API for
XML (SAX), StAX offers an API for writing XML documents. To be precise, it
offers two APIs: a low-level, cursor-based API (XMLStreamWriter), and a
higher-level, event-based API (XMLEventWriter). While the
cursor-based API is best used in data binding scenarios (for example, creating
a document from application data), the event-based API is typically used in
pipelining scenarios where a new document is constructed from the data of input
documents.

StAX
does not guarantee well-formed documents. It is still possible to produce a
document that violates the XML recommendation, such as a document with several
root elements or several XML prologues, or tag and attribute names containing
whitespace or characters not supported by XML. StAX implementations may check
these issues but they are not required to do so (the reference implementation
doesn't). Nevertheless, the StAX XMLStreamWriter is a big
improvement over outputting raw XML data, and it does this at a fraction of the
cost of using DOM.



--Venky

Re: [Axis 1.2]Deploying a Web Service under its own webapp.

[Vishist Mandapaka]

Hi,   The servlet mapping in web.xml needs to be modified. The following gives you an example of how to modify it. AxisServlet    /AxisServlet
        AxisServlet    *.jws    
    AxisServlet    /*  vishistOn 11/5/05, 
BASNARY Olivier <[EMAIL PROTECTED]> wrote:
Hi,I'am quite newbie in using Axis 1.2.I would like my web service to be accessed fromhttp://://instead ofhttp://:/axis/services/
For that, I made a jar of my web service and i put alltogether this jar and axis jars under awebapp/WEB-INF/lib directory. Then I made a War.My problem is that my webapp is concisting in only a
Web Service (I've got no other servlet thanAxisServlet).So, I can't manage doing a correct servlet mapping.I made a SOAP client to accesshttp://:// and
I receive a 404 HTTP Error. (???)My Web Service works fine when I put the jar underAxis webapp.For the moment, I use Tomcat 4.1.8.Any help would be great.Thanks in advance.
___Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! MessengerTéléchargez cette version sur 
http://fr.messenger.yahoo.com

[Axis 1.2]Deploying a Web Service under its own webapp.

[BASNARY Olivier]

Hi, 

I'am quite newbie in using Axis 1.2.

I would like my web service to be accessed from

http://://

instead of 

http://:/axis/services/

For that, I made a jar of my web service and i put all

together this jar and axis jars under a
webapp/WEB-INF/lib directory. Then I made a War.

My problem is that my webapp is concisting in only a
Web Service (I've got no other servlet than
AxisServlet).

So, I can't manage doing a correct servlet mapping.

I made a SOAP client to access
http://:// and
I receive a 404 HTTP Error. (???)

My Web Service works fine when I put the jar under
Axis webapp.

For the moment, I use Tomcat 4.1.8.

Any help would be great.

Thanks in advance.






___ 
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger 
Téléchargez cette version sur http://fr.messenger.yahoo.com