Axis 1.3 exception class doesn't inherit from java.lang.exception ( broken)

["Ali, Haneef" <ha...@hp.com>]

Hi,

In my WSDL I have a faultType say "MyFault". In Axis2_1.2 there used to
be a class called MyFaultException which inherited from
java.lang.Exception

In Axis2_1.3 there is no such class, but the generated class "MyFault"
doesn't inherit from java.lang.Exception. Generated stub/skeleton looks
like

	class MyStub{
		public class MyResponse myMethod (myRequest pRequest)
throws MyFault
	} 

Which obviously won't compile, since MyFault is not inherited from
java.lang.Exception.


Thanks,
Haneef

-----Original Message-----
From: Michael.Davis@servicecanada.gc.ca
[mailto:Michael.Davis@servicecanada.gc.ca] 
Sent: Tuesday, June 26, 2007 6:44 AM
To: axis-user@ws.apache.org
Subject: RE: Axis2 and SAML

Thanks again George,

That clears things up.

cheers,
md
 

> -----Original Message-----
> From: George Stanchev [mailto:Gstanchev@serena.com]
> Sent: Monday, June 25, 2007 6:26 PM
> To: axis-user@ws.apache.org
> Subject: RE: Axis2 and SAML
> 
> 
> Hi Michael,
> 
> In addition to be a structure for carrying identity information, SAML 
> defines different profiles, bindings, etc protocol related 
> specifications for requesting, canceling, verification, etc 
> manipulations of security tokens. In a sense it does the same thing as

> WS-Trust but for SAML-tokens while WS-Trust allows other tokens as 
> well. The internet2 Shibboleth project uses fully SAML-based identity 
> solution - you might want to check it out (google it, it will come 
> up).
> 
> Its not only the token, but how you request it, cancel it in secure 
> manner etc.
> 
> In addition, if you are building a web based single sign on solution, 
> you migh want to check the WS-Federation Passive Requestor profile, 
> which defines a standardized way of building web-based SSO solutions 
> which can be federated.
> 
> Best Regards,
> George
> 
> -----Original Message-----
> From: Michael.Davis@servicecanada.gc.ca 
> [mailto:Michael.Davis@servicecanada.gc.ca]
> Sent: Monday, June 25, 2007 9:10 AM
> To: axis-user@ws.apache.org
> Subject: RE: Axis2 and SAML
> 
> Thanks George,
> 
> For some reason it took me a whole week to come across this post.
> 
> Anyway, you say you'd recommend SAML, but you also say you prefer 
> WS-Trust. I'm a bit confused - I thought SAML was a language for 
> representing users and their permissions, whereas WS-Trust was for 
> exchanging security tokens. In other words, I thought these addressed 
> two different classes of use cases.
> 
> I'm still very new to this stuff... 
> 
> cheers,
> md
>  
> 
> > -----Original Message-----
> > From: George Stanchev [mailto:Gstanchev@serena.com]
> > Sent: Monday, June 18, 2007 12:15 PM
> > To: axis-user@ws.apache.org
> > Subject: RE: Axis2 and SAML
> > 
> > 
> > Hi Michael,
> > 
> > The support for SAML in Rampart is rather weak and if you go with 
> > SAML, do not expect much help from it. It uses is
> internally for the
> > more of a special case of WS-SecureConversation SC token.
> > In addition, in Rampart 1.1 there was a way to create a signed and 
> > unsigned SAML tokens but you get the token only in the
> outbound SOAP
> > and you don't have much control over what goes inside (for example 
> > SAML attributes).
> > 
> > I'd definetely recommend SAML as the way to go for tokens in an SSO 
> > implementation - it is standard, its been around for a while, its 
> > proven, it is signed and it is extensible. In addtion, the
> SAML 2.0 by
> 
> > it self defines a security "language" rivaling WS-Trust so you can 
> > just stay with it, though I prefer WS-Trust based exchanges as more 
> > standard and supported way to go.
> > 
> > Internet2's OpenSAML libraries are the only mature open source SAML 
> > libraries that I know of.
> > Version 1.1 supports SAML 1.0 and 1.1 and version 2
> supports all SAML
> > standards. OpenSAML2 is still being developed and even though it is 
> > stable for most parts it will change somewhat around some
> of the more
> > peripherical cases (Encryption is one that comes to mind). 
> Though it
> > does have a steeper learning curve, I'd start with OpenSAML2.
> > 
> > Good luck with the SSO implementation.
> > 
> > Best Regards,
> > George
> > 
> > -----Original Message-----
> > From: Michael.Davis@servicecanada.gc.ca 
> > [mailto:Michael.Davis@servicecanada.gc.ca]
> > Sent: Friday, June 15, 2007 2:36 PM
> > To: axis-user@ws.apache.org
> > Subject: Axis2 and SAML
> > 
> > Hi,
> > 
> > I'm working on a single-sign-on service for our organization's 
> > intranet.
> > The idea an application can send a username, and password and 
> > application identifier to the service, and the service
> responds with a
> 
> > list of permissions that the user has for the particular
> application.
> > 
> > Just to get started, I created a service that returns a string from 
> > which I can parse out what I need. But I'm wondering if I
> could gain
> > anything (such as greater interoperability) by using a
> standard such
> > as SAML to represent a user and his/her permissions.
> > 
> > I see that there is a framework for working with SAML:
> > http://www.opensaml.org/
> > 
> > Does this sound reasonable or am I heading in the wrong direction? 
> > Will I end up with a schema nightmare if I return a SAML
> xml document
> > as a service payload? BTW, I plan on writing the client and
> server by
> > hand, because later I will probably want to add rampart and
> have more
> > control over headers and stuff.
> > 
> > Thanks
> > Michael Davis
> > 
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-user-help@ws.apache.org
> > 
> > 
> > 
> > 
> **********************************************************************
> > This email and any files transmitted with it are confidential and 
> > intended solely for the use of the individual or entity to
> whom they
> > are addressed. Any unauthorized review, use, disclosure or 
> > distribution is prohibited. If you are not the intended recipient, 
> > please contact the sender by reply e-mail and destroy all copies of 
> > the original message.
> > 
> > 
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> > For additional commands, e-mail: axis-user-help@ws.apache.org
> > 
> > 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org