I'm trying to configure an environment with spring and tiles. So far I
manage to be successful running the local web server but when I upload
my app and run it I get this error:
org.springframework.beans.factory.BeanCreationException: Error
creating bean with name 'tilesConfigurer' defined in class path
resource [spring/web/tiles-config-applicationcontext.xml]: Invocation
of init method failed; nested exception is
java.security.AccessControlException: access denied
(java.lang.RuntimePermission setContextClassLoader)
..
Caused by: java.security.AccessControlException: access denied
(java.lang.RuntimePermission setContextClassLoader)
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at java.lang.Thread.setContextClassLoader(Unknown Source)
at org.apache.tiles.util.ClassUtil.instantiate(ClassUtil.java:82)
at org.apache.tiles.util.ClassUtil.instantiate(ClassUtil.java:48)
Again, this doesn't happen when I run my application locally.
as general idea - why AppEngine SDK does not contain the same
whitelist as runtime?
This will be very handy to check against this type of errors on dev.machine
On Tue, Apr 14, 2009 at 4:38 PM, Bruno Cardoso <bcardoso.h...@gmail.com> wrote:
> I'm trying to configure an environment with spring and tiles. So far I
> manage to be successful running the local web server but when I upload
> my app and run it I get this error:
> org.springframework.beans.factory.BeanCreationException: Error
> creating bean with name 'tilesConfigurer' defined in class path
> resource [spring/web/tiles-config-applicationcontext.xml]: Invocation
> of init method failed; nested exception is
> java.security.AccessControlException: access denied
> (java.lang.RuntimePermission setContextClassLoader)
> ..
> Caused by: java.security.AccessControlException: access denied
> (java.lang.RuntimePermission setContextClassLoader)
> at java.security.AccessControlContext.checkPermission(Unknown Source)
> at java.security.AccessController.checkPermission(Unknown Source)
> at java.lang.SecurityManager.checkPermission(Unknown Source)
> at java.lang.Thread.setContextClassLoader(Unknown Source)
> at org.apache.tiles.util.ClassUtil.instantiate(ClassUtil.java:82)
> at org.apache.tiles.util.ClassUtil.instantiate(ClassUtil.java:48)
> Again, this doesn't happen when I run my application locally.
> as general idea - why AppEngine SDK does not contain the same
> whitelist as runtime?
> This will be very handy to check against this type of errors on dev.machine
> On Tue, Apr 14, 2009 at 4:38 PM, Bruno Cardoso <bcardoso.h...@gmail.com> wrote:
> > I'm trying to configure an environment with spring and tiles. So far I
> > manage to be successful running the local web server but when I upload
> > my app and run it I get this error:
> > org.springframework.beans.factory.BeanCreationException: Error
> > creating bean with name 'tilesConfigurer' defined in class path
> > resource [spring/web/tiles-config-applicationcontext.xml]: Invocation
> > of init method failed; nested exception is
> > java.security.AccessControlException: access denied
> > (java.lang.RuntimePermission setContextClassLoader)
> > ..
> > Caused by: java.security.AccessControlException: access denied
> > (java.lang.RuntimePermission setContextClassLoader)
> > at java.security.AccessControlContext.checkPermission(Unknown Source)
> > at java.security.AccessController.checkPermission(Unknown Source)
> > at java.lang.SecurityManager.checkPermission(Unknown Source)
> > at java.lang.Thread.setContextClassLoader(Unknown Source)
> > at org.apache.tiles.util.ClassUtil.instantiate(ClassUtil.java:82)
> > at org.apache.tiles.util.ClassUtil.instantiate(ClassUtil.java:48)
> > Again, this doesn't happen when I run my application locally.
We don't currently grant user code permission to call
Thread.setContextClassLoader(). This is consistent in both the development
server and the production environment, so I don't know why you're seeing
different behavior from Tiles. Perhaps there is some other difference that
is triggering it.
Regardless, I think this code in Tiles could be written differently.
Assuming you're using this version:
It appears to be setting the context class loader temporarily during a
Class.forName() call, but I Class.forName(String) uses the calling class
loader rather than the context classloader. This code seems to be trying to
set the context classloader to the calling classloader anyway, so just
commenting out the setContextClassLoader() calls should do the trick.
Let me know if that helps,
Don
On Tue, Apr 14, 2009 at 11:20 AM, Bruno Cardoso <bcardoso.h...@gmail.com>wrote:
> On 14 Abr, 14:45, Nikolay Gorylenko <n0...@jug.ua> wrote:
> > as general idea - why AppEngine SDK does not contain the same
> > whitelist as runtime?
> > This will be very handy to check against this type of errors on
> dev.machine
> > On Tue, Apr 14, 2009 at 4:38 PM, Bruno Cardoso <bcardoso.h...@gmail.com>
> wrote:
> > > I'm trying to configure an environment with spring and tiles. So far I
> > > manage to be successful running the local web server but when I upload
> > > my app and run it I get this error:
> > > org.springframework.beans.factory.BeanCreationException: Error
> > > creating bean with name 'tilesConfigurer' defined in class path
> > > resource [spring/web/tiles-config-applicationcontext.xml]: Invocation
> > > of init method failed; nested exception is
> > > java.security.AccessControlException: access denied
> > > (java.lang.RuntimePermission setContextClassLoader)
> > > ..
> > > Caused by: java.security.AccessControlException: access denied
> > > (java.lang.RuntimePermission setContextClassLoader)
> > > at java.security.AccessControlContext.checkPermission(Unknown
> Source)
> > > at java.security.AccessController.checkPermission(Unknown
> Source)
> > > at java.lang.SecurityManager.checkPermission(Unknown Source)
> > > at java.lang.Thread.setContextClassLoader(Unknown Source)
> > > at
> org.apache.tiles.util.ClassUtil.instantiate(ClassUtil.java:82)
> > > at
> org.apache.tiles.util.ClassUtil.instantiate(ClassUtil.java:48)
> > > Again, this doesn't happen when I run my application locally.
> We don't currently grant user code permission to call
> Thread.setContextClassLoader(). This is consistent in both the development
> server and the production environment, so I don't know why you're seeing
> different behavior from Tiles. Perhaps there is some other difference that
> is triggering it.
> Regardless, I think this code in Tiles could be written differently.
> Assuming you're using this version:
> It appears to be setting the context class loader temporarily during a
> Class.forName() call, but I Class.forName(String) uses the calling class
> loader rather than the context classloader. This code seems to be trying to
> set the context classloader to the calling classloader anyway, so just
> commenting out the setContextClassLoader() calls should do the trick.
> Let me know if that helps,
> Don
> On Tue, Apr 14, 2009 at 11:20 AM, Bruno Cardoso <bcardoso.h...@gmail.com>wrote:
> > Any idea on how to resolve this issue?
> > On 14 Abr, 14:45, Nikolay Gorylenko <n0...@jug.ua> wrote:
> > > as general idea - why AppEngine SDK does not contain the same
> > > whitelist as runtime?
> > > This will be very handy to check against this type of errors on
> > dev.machine
> > > On Tue, Apr 14, 2009 at 4:38 PM, Bruno Cardoso <bcardoso.h...@gmail.com>
> > wrote:
> > > > I'm trying to configure an environment with spring and tiles. So far I
> > > > manage to be successful running the local web server but when I upload
> > > > my app and run it I get this error:
> > > > org.springframework.beans.factory.BeanCreationException: Error
> > > > creating bean with name 'tilesConfigurer' defined in class path
> > > > resource [spring/web/tiles-config-applicationcontext.xml]: Invocation
> > > > of init method failed; nested exception is
> > > > java.security.AccessControlException: access denied
> > > > (java.lang.RuntimePermission setContextClassLoader)
> > > > ..
> > > > Caused by: java.security.AccessControlException: access denied
> > > > (java.lang.RuntimePermission setContextClassLoader)
> > > > at java.security.AccessControlContext.checkPermission(Unknown
> > Source)
> > > > at java.security.AccessController.checkPermission(Unknown
> > Source)
> > > > at java.lang.SecurityManager.checkPermission(Unknown Source)
> > > > at java.lang.Thread.setContextClassLoader(Unknown Source)
> > > > at
> > org.apache.tiles.util.ClassUtil.instantiate(ClassUtil.java:82)
> > > > at
> > org.apache.tiles.util.ClassUtil.instantiate(ClassUtil.java:48)
> > > > Again, this doesn't happen when I run my application locally.
I imagine that if you reported this to the Tiles devs, they would be very
quick to fix it. Setting a Thread's contextClassLoader is not something you
can expect to be able to do in a sandboxed environment, and there is a very
trivial and reasonable fix.
On Wed, Apr 15, 2009 at 5:41 PM, Bruno Cardoso <bcardoso.h...@gmail.com>wrote:
> Well, this only happens in production. That I can confirm. I can send
> you a zip file with the app so you can test it out.
> Changing a third party library is something that I really would like
> to avoid so I guess I won't be able to use tiles with GAE.
> On Apr 14, 5:44 pm, Don Schwarz <schwa...@google.com> wrote:
> > Hi Bruno,
> > We don't currently grant user code permission to call
> > Thread.setContextClassLoader(). This is consistent in both the
> development
> > server and the production environment, so I don't know why you're seeing
> > different behavior from Tiles. Perhaps there is some other difference
> that
> > is triggering it.
> > Regardless, I think this code in Tiles could be written differently.
> > Assuming you're using this version:
> > It appears to be setting the context class loader temporarily during a
> > Class.forName() call, but I Class.forName(String) uses the calling class
> > loader rather than the context classloader. This code seems to be trying
> to
> > set the context classloader to the calling classloader anyway, so just
> > commenting out the setContextClassLoader() calls should do the trick.
> > Let me know if that helps,
> > Don
> > On Tue, Apr 14, 2009 at 11:20 AM, Bruno Cardoso <bcardoso.h...@gmail.com
> >wrote:
> > > Any idea on how to resolve this issue?
> > > On 14 Abr, 14:45, Nikolay Gorylenko <n0...@jug.ua> wrote:
> > > > as general idea - why AppEngine SDK does not contain the same
> > > > whitelist as runtime?
> > > > This will be very handy to check against this type of errors on
> > > dev.machine
> > > > On Tue, Apr 14, 2009 at 4:38 PM, Bruno Cardoso <
> bcardoso.h...@gmail.com>
> > > wrote:
> > > > > I'm trying to configure an environment with spring and tiles. So
> far I
> > > > > manage to be successful running the local web server but when I
> upload
> > > > > my app and run it I get this error:
> I imagine that if you reported this to the Tiles devs, they would be very
> quick to fix it. Setting a Thread's contextClassLoader is not something you
> can expect to be able to do in a sandboxed environment, and there is a very
> trivial and reasonable fix.
> On Wed, Apr 15, 2009 at 5:41 PM, Bruno Cardoso <bcardoso.h...@gmail.com>wrote:
> > Well, this only happens in production. That I can confirm. I can send
> > you a zip file with the app so you can test it out.
> > Changing a third party library is something that I really would like
> > to avoid so I guess I won't be able to use tiles with GAE.
> > On Apr 14, 5:44 pm, Don Schwarz <schwa...@google.com> wrote:
> > > Hi Bruno,
> > > We don't currently grant user code permission to call
> > > Thread.setContextClassLoader(). This is consistent in both the
> > development
> > > server and the production environment, so I don't know why you're seeing
> > > different behavior from Tiles. Perhaps there is some other difference
> > that
> > > is triggering it.
> > > Regardless, I think this code in Tiles could be written differently.
> > > Assuming you're using this version:
> > > It appears to be setting the context class loader temporarily during a
> > > Class.forName() call, but I Class.forName(String) uses the calling class
> > > loader rather than the context classloader. This code seems to be trying
> > to
> > > set the context classloader to the calling classloader anyway, so just
> > > commenting out the setContextClassLoader() calls should do the trick.
> > > Let me know if that helps,
> > > Don
> > > On Tue, Apr 14, 2009 at 11:20 AM, Bruno Cardoso <bcardoso.h...@gmail.com
> > >wrote:
> > > > Any idea on how to resolve this issue?
> > > > On 14 Abr, 14:45, Nikolay Gorylenko <n0...@jug.ua> wrote:
> > > > > as general idea - why AppEngine SDK does not contain the same
> > > > > whitelist as runtime?
> > > > > This will be very handy to check against this type of errors on
> > > > dev.machine
> > > > > On Tue, Apr 14, 2009 at 4:38 PM, Bruno Cardoso <
> > bcardoso.h...@gmail.com>
> > > > wrote:
> > > > > > I'm trying to configure an environment with spring and tiles. So
> > far I
> > > > > > manage to be successful running the local web server but when I
> > upload
> > > > > > my app and run it I get this error:
> On Apr 15, 11:04 pm, Toby Reyelts <to...@google.com> wrote:
> > Bruno,
> > I imagine that if you reported this to the Tiles devs, they would be very
> > quick to fix it. Setting a Thread's contextClassLoader is not something you
> > can expect to be able to do in a sandboxed environment, and there is a very
> > trivial and reasonable fix.
> > On Wed, Apr 15, 2009 at 5:41 PM, Bruno Cardoso <bcardoso.h...@gmail.com>wrote:
> > > Well, this only happens in production. That I can confirm. I can send
> > > you a zip file with the app so you can test it out.
> > > Changing a third party library is something that I really would like
> > > to avoid so I guess I won't be able to use tiles with GAE.
> > > On Apr 14, 5:44 pm, Don Schwarz <schwa...@google.com> wrote:
> > > > Hi Bruno,
> > > > We don't currently grant user code permission to call
> > > > Thread.setContextClassLoader(). This is consistent in both the
> > > development
> > > > server and the production environment, so I don't know why you're seeing
> > > > different behavior from Tiles. Perhaps there is some other difference
> > > that
> > > > is triggering it.
> > > > Regardless, I think this code in Tiles could be written differently.
> > > > Assuming you're using this version:
> > > > It appears to be setting the context class loader temporarily during a
> > > > Class.forName() call, but I Class.forName(String) uses the calling class
> > > > loader rather than the context classloader. This code seems to be trying
> > > to
> > > > set the context classloader to the calling classloader anyway, so just
> > > > commenting out the setContextClassLoader() calls should do the trick.
> > > > Let me know if that helps,
> > > > Don
> > > > On Tue, Apr 14, 2009 at 11:20 AM, Bruno Cardoso <bcardoso.h...@gmail.com
> > > >wrote:
> > > > > Any idea on how to resolve this issue?
> > > > > On 14 Abr, 14:45, Nikolay Gorylenko <n0...@jug.ua> wrote:
> > > > > > as general idea - why AppEngine SDK does not contain the same
> > > > > > whitelist as runtime?
> > > > > > This will be very handy to check against this type of errors on
> > > > > dev.machine
> > > > > > On Tue, Apr 14, 2009 at 4:38 PM, Bruno Cardoso <
> > > bcardoso.h...@gmail.com>
> > > > > wrote:
> > > > > > > I'm trying to configure an environment with spring and tiles. So
> > > far I
> > > > > > > manage to be successful running the local web server but when I
> > > upload
> > > > > > > my app and run it I get this error:
> > > I imagine that if you reported this to the Tiles devs, they would be
> very
> > > quick to fix it. Setting a Thread's contextClassLoader is not something
> you
> > > can expect to be able to do in a sandboxed environment, and there is a
> very
> > > trivial and reasonable fix.
> > > On Wed, Apr 15, 2009 at 5:41 PM, Bruno Cardoso <
> bcardoso.h...@gmail.com>wrote:
> > > > Well, this only happens in production. That I can confirm. I can send
> > > > you a zip file with the app so you can test it out.
> > > > Changing a third party library is something that I really would like
> > > > to avoid so I guess I won't be able to use tiles with GAE.
> > > > On Apr 14, 5:44 pm, Don Schwarz <schwa...@google.com> wrote:
> > > > > Hi Bruno,
> > > > > We don't currently grant user code permission to call
> > > > > Thread.setContextClassLoader(). This is consistent in both the
> > > > development
> > > > > server and the production environment, so I don't know why you're
> seeing
> > > > > different behavior from Tiles. Perhaps there is some other
> difference
> > > > that
> > > > > is triggering it.
> > > > > Regardless, I think this code in Tiles could be written
> differently.
> > > > > Assuming you're using this version:
> > > > > It appears to be setting the context class loader temporarily
> during a
> > > > > Class.forName() call, but I Class.forName(String) uses the calling
> class
> > > > > loader rather than the context classloader. This code seems to be
> trying
> > > > to
> > > > > set the context classloader to the calling classloader anyway, so
> just
> > > > > commenting out the setContextClassLoader() calls should do the
> trick.
> > > > > Let me know if that helps,
> > > > > Don
> > > > > On Tue, Apr 14, 2009 at 11:20 AM, Bruno Cardoso <
> bcardoso.h...@gmail.com
> > > > >wrote:
> > > > > > Any idea on how to resolve this issue?
> > > > > > On 14 Abr, 14:45, Nikolay Gorylenko <n0...@jug.ua> wrote:
> > > > > > > as general idea - why AppEngine SDK does not contain the same
> > > > > > > whitelist as runtime?
> > > > > > > This will be very handy to check against this type of errors on
> > > > > > dev.machine
> > > > > > > On Tue, Apr 14, 2009 at 4:38 PM, Bruno Cardoso <
> > > > bcardoso.h...@gmail.com>
> > > > > > wrote:
> > > > > > > > I'm trying to configure an environment with spring and tiles.
> So
> > > > far I
> > > > > > > > manage to be successful running the local web server but when
> I
> > > > upload
> > > > > > > > my app and run it I get this error:
|
