Hi Folks
I'm writing a Dynamic Client to invoke a non axis WS the client is written
with axis2 AXIOM with no stubs generation.This service deals with only
simple types no complex types involve here.WS is about concatenating two
string.The same service works fine with normal stubs generation method
restriction!
> java.lang.UnsupportedClassVersionError: org/apache/axis2/AxisFault
> (Unsupported major.minor version 49.0)
> -
>
> Key: AXIS2-4376
>
with jdk1.4. We are not stuck on 1.4 ;-)
But the supported JDK versions should be written on the main page !
Sebastien
2009/6/14 Deepal Jayasinghe (JIRA)
> java.lang.UnsupportedClassVersionError: org/apache/axis2/AxisFault
> (Unsupported major.minor ve
orry, we decided to support JDK 1.5 and above form Axis2 1.5 release.
There are a number of reason behind that, and code is also made JDK 1.5
compatible, so there is no way we can go back to 1.4.
Thank you!
Deepal
> java.lang.UnsupportedClassVersionError: org/apache/axis2/AxisFault
> (U
java.lang.UnsupportedClassVersionError: org/apache/axis2/AxisFault (Unsupported
major.minor version 49.0)
-
Key: AXIS2-4376
URL: https://issues.apache.org
Can you post the WSDL?
Sanjiva.
Sharon wrote:
The next signature :
public OMElement getProjectName(){
}
Generates 132 lines WSDL length
And 160K (2300 lines) Stub size using WSDL2JAVA
The next signature :
public OMElement getProjectName() throws AxisFault {
}
Generates 1032 lines WSDL length
The next signature :
public OMElement getProjectName(){
}
Generates 132 lines WSDL length
And 160K (2300 lines) Stub size using WSDL2JAVA
The next signature :
public OMElement getProjectName() throws AxisFault {
}
Generates 1032 lines WSDL length
And 5000K (100K lines) Stub size using WSDL2JAVA
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Nicholas L Gallardo wrote:
>
> There seems to be some ambiguous behavior, to me at least, in the
> AxisFault that I was hoping someone could clarify. Specifically, the
> following comment threw me off:
>
> /**
> * This is just a convenienc
There seems to be some ambiguous behavior, to me at least, in the
AxisFault that I was hoping someone could clarify. Specifically, the
following comment threw me off:
/**
* This is just a convenience method for the user. If you set these,
do not use other methods
* in this class
Eran Chinthaka wrote:
Hi Steve,
Any plans of completing this ? Its been a long time you made these
changes, but still they are in a transition stage.
Initialy I implemented AxisFault and included some stuff based on
OMElements. But you have changed them and included a parallel
hierarchy. Assumi
Hi Steve,
Any plans of completing this ? Its been a long time you made these
changes, but still they are in a transition stage.
Initialy I implemented AxisFault and included some stuff based on
OMElements. But you have changed them and included a parallel
hierarchy. Assuming its fine (but I can r
Steve Loughran wrote:
>
> There is some fun here in that we have different faults for SOAP1.1
> and SOAP1.2. So while I could ask for a fault, I have to decide
> whether it is 1.1 or 1.2. hmm.
Did you look at how existing code handles that ? See the interfaces I
have put and I hope you agree
Steve Loughran wrote:
I am looking at the current axis fault stuff. Is anybody actively
working on this, or am I free to add enhancements?
Specifically:
1. All the bits of a SOAPFAult, including random XML
easily added to AxisFault, along with headers. Can put this stuff in
when an except
Glen Daniels wrote:
+1
Axis 1.X's AxisFault does have the capability to add and access headers
as you request below. You might want to crib whatever you can from there.
That is exactly my plan.
We might explore the utility of a WS-Addressing-specific fault subclass
which gives a nice API o
+1
Axis 1.X's AxisFault does have the capability to add and access headers
as you request below. You might want to crib whatever you can from there.
We might explore the utility of a WS-Addressing-specific fault subclass
which gives a nice API on top of the header-related stuff.
--G
Sanji
Most definitely +1 .. go for it!
Sanjiva.
On Wed, 2005-10-26 at 12:01 +0100, Steve Loughran wrote:
> I am looking at the current axis fault stuff. Is anybody actively
> working on this, or am I free to add enhancements?
>
> Specifically:
>
> 1. All the bits of a SOAPFAult, including random XML
Steve Loughran wrote:
>
> I am looking at the current axis fault stuff. Is anybody actively
> working on this, or am I free to add enhancements?
I "was" working on this and I know this is not complete. If you can
please please go ahead and do it.
>
> Specifically:
>
> 1. All the bits of a SOAP
I am looking at the current axis fault stuff. Is anybody actively
working on this, or am I free to add enhancements?
Specifically:
1. All the bits of a SOAPFAult, including random XML
2. Axis1 features: stack trace extractions, hostname, http error codes.
3. Tweak how we map from a java fau
Eran Chinthaka wrote:
Hi,
Steve Loughran wrote:
Eran Chinthaka wrote:
See here (http://issues.apache.org/jira/browse/AXIS2-232).
Just added a JIRA to make sure we will keep track of this.
Thanks Steve for the comments (and for the disappointing blog entry
;-) )
oh dont take it persona
Hi,
Steve Loughran wrote:
Eran Chinthaka wrote:
See here (http://issues.apache.org/jira/browse/AXIS2-232).
Just added a JIRA to make sure we will keep track of this.
Thanks Steve for the comments (and for the disappointing blog entry
;-) )
oh dont take it personally.
Nothing is perso
Eran Chinthaka wrote:
See here (http://issues.apache.org/jira/browse/AXIS2-232).
Just added a JIRA to make sure we will keep track of this.
Thanks Steve for the comments (and for the disappointing blog entry ;-) )
oh dont take it personally.
I quite like one aspect of the design, the interf
See here (http://issues.apache.org/jira/browse/AXIS2-232).
Just added a JIRA to make sure we will keep track of this.
Thanks Steve for the comments (and for the disappointing blog entry ;-) )
Steve Loughran wrote:
The Axis2 fault is a lot more minimal than the Axis1 one. Is the
reason for
The Axis2 fault is a lot more minimal than the Axis1 one. Is the reason
for this just lack of time/effort, or does it reflect a different view
on how SOAPFaults should be handled?
-steve
23 matches
Mail list logo
