Making XStream compatible with the Google App Engine.

[Paul Hammant-3]

One of other of these patches (or something better still) will make  
XStream compatible with GAE.











Joe likes neither for the record ;-)
I trust that y'all will do the right thing.

Enjoy,

- Paul

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jörg Schaible-2]

Hi Paul,

Paul Hammant wrote at Mittwoch, 8. April 2009 08:30:

> One of other of these patches (or something better still) will make
> XStream compatible with GAE.

> Joe likes neither for the record ;-)

Me too :-)

> I trust that y'all will do the right thing.

Well, in first place I'd like to know what the patch really tries to solve?
Why can't GAE run with the current implementation?

- Jörg



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Paul Hammant-3]

Its security policies Jörg

They have them in place to veto setAccessible to restricted classes,  
as well as other things that might be classes as "breaking out of the  
sanbdox"

Have you signed up for an appengine beta account ?
You'll only find the exceptions in the live service and not in the SDK  
that runs localhost..

Regards,

- Paul

On Apr 8, 2009, at 12:26 AM, Jörg Schaible wrote:

> Hi Paul,
>
> Paul Hammant wrote at Mittwoch, 8. April 2009 08:30:
>
>> One of other of these patches (or something better still) will make
>> XStream compatible with GAE.
>
>> Joe likes neither for the record ;-)
>
> Me too :-)
>
>> I trust that y'all will do the right thing.
>
> Well, in first place I'd like to know what the patch really tries to  
> solve?
> Why can't GAE run with the current implementation?
>
> - Jörg
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jörg Schaible-2]

Hi Paul,

Paul Hammant wrote:

> Its security policies Jörg
>
> They have them in place to veto setAccessible to restricted classes,
> as well as other things that might be classes as "breaking out of the
> sanbdox"

What I found is
http://www.byteonic.com/2009/nine-things-you-cannot-do-using-java-in-google-app-engine/.
However, none of this really explains the patch in its current form. This
seems more a blind lazy initialization for all static initializers
regarding a field. And I say really "blind", because e.g. the
HarmonyReflectionProvider is explicitly excluded from the XStream build,
since it is not compilable currently from Maven nor is it part of any
release. Additionally if you say "security policies" I wonder, if you're
able to use the Sun14ReflectionProvider at all (lazy or not). Therefore I
still like to know, what exactly fails and how the exception (and stack
trace) looks like. My guess is that GAE only prevents the access to the
com.sun.* stuff in the Sun14ReflectionProvider, but the rest is simply not
necessary.

> Have you signed up for an appengine beta account ?

No, not yet - and I have to say that I am currently somewhat overloaded to
do so ... ;-)

> You'll only find the exceptions in the live service and not in the SDK
> that runs localhost..

If localhost does not have the security policy, can you at least run
JVM.main there to give me some idea about the environment?

- Jörg


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Paul Hammant-3]

It was an infuriating amount of time to go through and I only patched  
things where I caught an exception.  Basically I trial-and-error'd my  
way though a huge amount of deployments until I had it working.  All  
under a veil of secrecy a couple of months ago.  The downloaded SDK  
does not exhibit the same security policy, thus I can't prove  
correctness locally.  The remote (live) service has closed down some  
of the env-var lookups to prevent too much discovery of what Google  
are running.

The second patch ( faster_safer.patch ) was a start from scratch based  
on what I had learned.

I need to get something out there, its holding up lots for me.  Would  
you mind if I released something to the picocontainer maven group that  
was clear a "for-gae & patched" with something in and around a version  
number of 1.3.1 ?

After that, I am happy to wait for ages for the XStream team to do  
this the right way :)

Regards,

- Paul

On Apr 14, 2009, at 1:05 PM, Jörg Schaible wrote:

> Hi Paul,
>
> Paul Hammant wrote:
>
>> Its security policies Jörg
>>
>> They have them in place to veto setAccessible to restricted classes,
>> as well as other things that might be classes as "breaking out of the
>> sanbdox"
>
> What I found is
> http://www.byteonic.com/2009/nine-things-you-cannot-do-using-java-in-google-app-engine/ 
> .
> However, none of this really explains the patch in its current form.  
> This
> seems more a blind lazy initialization for all static initializers
> regarding a field. And I say really "blind", because e.g. the
> HarmonyReflectionProvider is explicitly excluded from the XStream  
> build,
> since it is not compilable currently from Maven nor is it part of any
> release. Additionally if you say "security policies" I wonder, if  
> you're
> able to use the Sun14ReflectionProvider at all (lazy or not).  
> Therefore I
> still like to know, what exactly fails and how the exception (and  
> stack
> trace) looks like. My guess is that GAE only prevents the access to  
> the
> com.sun.* stuff in the Sun14ReflectionProvider, but the rest is  
> simply not
> necessary.
>
>> Have you signed up for an appengine beta account ?
>
> No, not yet - and I have to say that I am currently somewhat  
> overloaded to
> do so ... ;-)
>
>> You'll only find the exceptions in the live service and not in the  
>> SDK
>> that runs localhost..
>
> If localhost does not have the security policy, can you at least run
> JVM.main there to give me some idea about the environment?
>
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jörg Schaible-2]

Hi Paul,

Paul Hammant wrote:

> It was an infuriating amount of time to go through and I only patched
> things where I caught an exception.  Basically I trial-and-error'd my
> way though a huge amount of deployments until I had it working.  All
> under a veil of secrecy a couple of months ago.  The downloaded SDK
> does not exhibit the same security policy, thus I can't prove
> correctness locally.  The remote (live) service has closed down some
> of the env-var lookups to prevent too much discovery of what Google
> are running.
>
> The second patch ( faster_safer.patch ) was a start from scratch based
> on what I had learned.

Gosh, I have to apologize. I completely missed the second patch in your
initial mail. Can you actually open a JIRA issue for that one?

> I need to get something out there, its holding up lots for me.  Would
> you mind if I released something to the picocontainer maven group that
> was clear a "for-gae & patched" with something in and around a version
> number of 1.3.1 ?

IMHO you actually don't have to. As I've explained before, you can still
derive from XStream your own facade, overload the setupConverter method
using the patched version and registering a private version of the
ExternalizableConverter, provide a PureJavaReflectionProvider in the ctor
(to avoid JVM.betReflectionProvider()) that is initialized with a private
copy of the FieldDictionary. That's it. You don't have to expose these
classes even in Pico's public API.

> After that, I am happy to wait for ages for the XStream team to do
> this the right way :)

The only action after a release that contains your changes is to drop your
private stuff again ...

- Jörg


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Paul Hammant-3]

Bug report :- http://jira.codehaus.org/browse/XSTR-566

Will report back on PureJavaReflectionProvider experiments.

Regards,

- Paul

On Apr 14, 2009, at 2:22 PM, Jörg Schaible wrote:

> Hi Paul,
>
> Paul Hammant wrote:
>
>> It was an infuriating amount of time to go through and I only patched
>> things where I caught an exception.  Basically I trial-and-error'd my
>> way though a huge amount of deployments until I had it working.  All
>> under a veil of secrecy a couple of months ago.  The downloaded SDK
>> does not exhibit the same security policy, thus I can't prove
>> correctness locally.  The remote (live) service has closed down some
>> of the env-var lookups to prevent too much discovery of what Google
>> are running.
>>
>> The second patch ( faster_safer.patch ) was a start from scratch  
>> based
>> on what I had learned.
>
> Gosh, I have to apologize. I completely missed the second patch in  
> your
> initial mail. Can you actually open a JIRA issue for that one?
>
>> I need to get something out there, its holding up lots for me.  Would
>> you mind if I released something to the picocontainer maven group  
>> that
>> was clear a "for-gae & patched" with something in and around a  
>> version
>> number of 1.3.1 ?
>
> IMHO you actually don't have to. As I've explained before, you can  
> still
> derive from XStream your own facade, overload the setupConverter  
> method
> using the patched version and registering a private version of the
> ExternalizableConverter, provide a PureJavaReflectionProvider in the  
> ctor
> (to avoid JVM.betReflectionProvider()) that is initialized with a  
> private
> copy of the FieldDictionary. That's it. You don't have to expose these
> classes even in Pico's public API.
>
>> After that, I am happy to wait for ages for the XStream team to do
>> this the right way :)
>
> The only action after a release that contains your changes is to  
> drop your
> private stuff again ...

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email