OpenSAML user discussion

["Anderson Jonathan" <>]

Actually, I agree with your design.  I myself love enforcing object
immutability.  I think the constraints that Axis's BeanSerializerFactory
place on constructor design are ridiculous - and I'm not sure if it's Axis's
fault or JAX-RPC's fault.  How hard would it be to specify to a SOAP engine
which constructor to use?  <sigh>

A possible solution would be to write custom OpenSAML serializers and
deserializers for Axis.  Axis also has their proprietary "message" style
service the just hands off the SOAP body to your method as a DOM,
essentially leaving serialization issues up to the service implementer.
This is a clear option as well, but it's not JAX-RPC compliant.  Again -
hate the spec or hate the impl?

But I cannot imagine that I'm the first person to try using OpenSAML with
Axis, am I?  How is everybody else doing it?

Thanks Scott.  Yell at Dims for me next time you guys are discussing
Axis/OpenSAML interop.  :)

        -Jon

-----Original Message-----
From: Scott Cantor 
[mailto:]
Sent: Thursday, October 16, 2003 2:56 PM
To: 'Anderson Jonathan'; 

Subject: RE: OpenSAML 0.9 and Apache Axis?


> Has anyone attempted to deploy Apache Axis web services that
> accept and return OpenSAML objects?  Because OpenSAML objects
> don't fit the standard JavaBean no-arg constructor with
> public getters and setters pattern I'm in deploy.wsdd
> typeMapping hell.  Anybody found a solution?  Am I missing
> something fundamental?

Sorry, it hasn't come up before, but I obviously am interested in it
working. I'm willing to adjust within reason if it will help.

The reason why I didn't use a propget/set model (independent of the JavaBean
issue, I know little about it) is that when I parse in an object from
serialized form, it's basically read-only. I can get around this by simply
allowing propsets when building, and toss out exceptions if it's a read-only
parsed object.

I'm just worried about Axis or what not thinking that a parsed object is
freely manipulatable. I could only allow that if I threw away the XML
representation (basically a marshal/unmarshal approach) and that means
constant reassembling and reparsing I expressly tried to avoid.

-- Scott



---------------------------------------------------mace-opensaml-users-+
For list utilities, archives, subscribe, unsubscribe, etc. please visit the
ListProc web interface at 

    http://archives.internet2.edu/

---------------------------------------------------mace-opensaml-users--