> 3. weld-core > I have changed catching exception from ResourceLoadingException to > Throwable. It is widest possible catch declaration, in fact catching > specific exceptions would be probably better or GAE exceptions should > be catch deeper and rethrown as ResourceLoadingException. > > There is problem with adding this classes during deployment: > org.jboss.seam.solder.bean.generic.GenericBeanExtension$1 > org.jboss.seam.solder.util.collections.AbstractMultiset$ElementSet$1 > org.jboss.logging.JBossLogManagerProvider > org.jboss.seam.solder.bean.defaultbean.DefaultBeanExtension$1 > org.jboss.seam.solder.util.collections.AbstractMultimap$KeySet$1 > org.jboss.logging.Log4jLogger > org.jboss.logging.JBossLogManagerLogger > >>> Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission accessDeclaredMembers) What exactly is the issue here? Reflection should still work on GAE.

> 4. weld-core > In InstantiatorFactory I have commented out adding > ReflectionFactoryInstantiator. It is not allowed to use > ReflectionFactory on GAE. Adding reflection factory should be check > programmatically before creating new instance in some if clause. > >>> java.lang.NoClassDefFoundError: sun.reflect.ReflectionFactory is a restricted class. Please see the Google App Engine developer's guide for more details. >>>     at com.google.appengine.runtime.Request.process-609c29691be26e8f(Request.java) >>>     at sun.reflect.ReflectionFactory.<clinit>(ReflectionFactory.java) >>>     at java.lang.reflect.Method.invoke(Method.java:43) >>>   at org.jboss.weld.util.reflection.instantiation.ReflectionFactoryInstantiator.<init>(ReflectionFactoryInstantiator.java:45) This looks like RFI should catch Throwable instead of Exception in ctor. And I haven't hit this. When does InstantiatorFactory get used?

> I have not tested yet which solder features are working and which ones > not. In wicket page injection works as expected. Solder works for me, but I only use @Resource handling atm. > If you are interested in providing support for GAE, I think it would > be great to have this changes apply to master branch. Some of them > (especially 3 and 4) need some more development and propably support > from weld team. If you can provide some example / test, I'll definitely have a look at this.

I'm playing with GAE for some JavaEE+GAE portability POC, I'll post about exactly what I'm doing asap -- probably around JBW time. -Ales

>>> 3. weld-core >>> I have changed catching exception from ResourceLoadingException to >>> Throwable. It is widest possible catch declaration, in fact catching >>> specific exceptions would be probably better or GAE exceptions should >>> be catch deeper and rethrown as ResourceLoadingException. >>> >>> There is problem with adding this classes during deployment: >>> org.jboss.seam.solder.bean.generic.GenericBeanExtension$1 >>> org.jboss.seam.solder.util.collections.AbstractMultiset$ElementSet$1 >>> org.jboss.logging.JBossLogManagerProvider >>> org.jboss.seam.solder.bean.defaultbean.DefaultBeanExtension$1 >>> org.jboss.seam.solder.util.collections.AbstractMultimap$KeySet$1 >>> org.jboss.logging.Log4jLogger >>> org.jboss.logging.JBossLogManagerLogger >>> >>>>> Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission accessDeclaredMembers) >> >> What exactly is the issue here? >> Reflection should still work on GAE. > Issue is related to the fact that the method > java.lang.Class.getGeneric* are not fully implemented on App Engine's > JDK. I think this is similar to > http://code.google.com/p/googleappengine/issues/detail?id=4250. >> >>> 4. weld-core >>> In InstantiatorFactory I have commented out adding >>> ReflectionFactoryInstantiator. It is not allowed to use >>> ReflectionFactory on GAE. Adding reflection factory should be check >>> programmatically before creating new instance in some if clause. >>> >>>>> java.lang.NoClassDefFoundError: sun.reflect.ReflectionFactory is a restricted class. Please see the Google App Engine developer's guide for more details. >>>>>     at com.google.appengine.runtime.Request.process-609c29691be26e8f(Request.java) >>>>>     at sun.reflect.ReflectionFactory.<clinit>(ReflectionFactory.java) >>>>>     at java.lang.reflect.Method.invoke(Method.java:43) >>>>>   at org.jboss.weld.util.reflection.instantiation.ReflectionFactoryInstantiator.<init>(ReflectionFactoryInstantiator.java:45) >> >> This looks like RFI should catch Throwable instead of Exception in ctor. >> >> And I haven't hit this. >> When does InstantiatorFactory get used? Yeah, "unproxyable" bean, which then needs JDK "hacks". Could that Wicket bean be changed, to be proxyable by default mechanism?

> Maybe some class from wicket module initiates that. Full stacktrace is: > Uncaught exception from servlet > java.lang.NoClassDefFoundError: sun.reflect.ReflectionFactory is a > restricted class. Please see the Google App Engine developer's guide > for more details. >       at com.google.appengine.runtime.Request.process-609c29691be26e8f(Request.java) >       at sun.reflect.ReflectionFactory.<clinit>(ReflectionFactory.java) >       at java.lang.reflect.Method.invoke(Method.java:43) >       at org.jboss.weld.util.reflection.instantiation.ReflectionFactoryInstantiator.<init>(ReflectionFactoryInstantiator.java:45) >       at org.jboss.weld.util.reflection.instantiation.InstantiatorFactory$1.<init>(InstantiatorFactory.java:41) >       at org.jboss.weld.util.reflection.instantiation.InstantiatorFactory.<clinit>(InstantiatorFactory.java:37) >       at org.jboss.weld.util.Proxies.getUnproxyableClassException(Proxies.java:228) >       at org.jboss.weld.util.Proxies.getUnproxyableTypeException(Proxies.java:166) >       at org.jboss.weld.util.Proxies.getUnproxyableTypesException(Proxies.java:191) >       at org.jboss.weld.util.Proxies.isTypesProxyable(Proxies.java:180) >       at org.jboss.weld.bean.ManagedBean.<init>(ManagedBean.java:328) >       at org.jboss.weld.bean.ManagedBean.of(ManagedBean.java:293) >       at org.jboss.weld.bootstrap.AbstractBeanDeployer.createManagedBean(AbstractBeanDeployer.java:239) >       at org.jboss.weld.bootstrap.BeanDeployer.createBeans(BeanDeployer.java:156) >       at org.jboss.weld.bootstrap.BeanDeployment.deployBeans(BeanDeployment.java:216) >       at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:370) >       at org.jboss.weld.environment.servlet.Listener.contextInitialized(Listener.java:205) >       at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:548) >       at org.mortbay.jetty.servlet.Context.startContext(Context.java:136) >       at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1250) >       at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517) >       at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:467) >       at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) >       at com.google.net.rpc.impl.RpcUtil.runRpcInApplication(RpcUtil.java:437) >       at com.google.net.rpc.impl.Server$RpcTask.runInContext(Server.java:573) >       at com.google.tracing.TraceContext$TraceContextRunnable$1.run(TraceContext.java:448) >       at com.google.tracing.TraceContext.runInContext(TraceContext.java:688) >       at com.google.tracing.TraceContext$AbstractTraceContextCallback.runInInheritedContextNoUnref(TraceContext.java:326) >       at com.google.tracing.TraceContext$AbstractTraceContextCallback.runInInheritedContext(TraceContext.java:318) >       at com.google.tracing.TraceContext$TraceContextRunnable.run(TraceContext.java:446) >       at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) >       at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) >       at java.lang.Thread.run(Thread.java:636) >> >>> I have not tested yet which solder features are working and which ones >>> not. In wicket page injection works as expected. >> >> Solder works for me, but I only use @Resource handling atm. >> >>> If you are interested in providing support for GAE, I think it would >>> be great to have this changes apply to master branch. Some of them >>> (especially 3 and 4) need some more development and propably support >>> from weld team. >> >> If you can provide some example / test, I'll definitely have a look at this. > I'm working on that application https://github.com/endpoint/widgetly. > Currently there is only integration stuff so you can treat it as test > case. > All of the changes I need to make I have done in separate branches in > my fork repositories: > Solder:  https://github.com/smigielski/solder/tree/deployOnGAE > Wicket: https://github.com/smigielski/wicket/tree/deployOnGAE > Weld https://github.com/smigielski/core/tree/deployOnGAE > >> >> I'm playing with GAE for some JavaEE+GAE portability POC, >> I'll post about exactly what I'm doing asap -- probably around JBW time. >> >> -Ales >> >> > When I was writing that email I had forgotten about one more issue: > 5. solder-api > > In class LoggerProviders I have moved > final LogManager jdkLogManager = LogManager.getLogManager(); > into try-catch block. java.util.logging.LogManager is a restricted class. This one is already known, and the patch to logging and solder were already submitted.

Hi, I have found one more problem with Weld on GAE. Session context objects, wchich are allready in the session, are not written back to session after any modification. Problem is due to session serialization optimization that are implemented in GAE. After each request all session objects are serialized and store in memcache or datastore. When you access object via getAttribute you get clone of serialized object and it not store back until you put it back in session with setAttribute method. It is no matter when you invoke setAttribute, it only marks this object to be serialized back at the end of the request. For my needs I've added fix to invoke setAttribute just after any not null object is retrieved from session in AbstractSessionBeanStore. https://github.com/smigielski/core/commit/e6d40d736710dded13738d83eb1f8d8.... Should I submit issues with deploying seam or weld on GAE into jira? If so, should it be marked any special way? Marek On Fri, Apr 22, 2011 at 10:41 PM, Marek Śmigielski <marek.smigielski(a)gmail.com&gt; wrote: > On Thu, Apr 21, 2011 at 1:29 PM, Ales Justin <ales.justin(a)gmail.com&gt; wrote: >>>>> 3. weld-core >>>>> I have changed catching exception from ResourceLoadingException to >>>>> Throwable. It is widest possible catch declaration, in fact catching >>>>> specific exceptions would be probably better or GAE exceptions should >>>>> be catch deeper and rethrown as ResourceLoadingException. >>>>> >>>>> There is problem with adding this classes during deployment: >>>>> org.jboss.seam.solder.bean.generic.GenericBeanExtension$1 >>>>> org.jboss.seam.solder.util.collections.AbstractMultiset$ElementSet$1 >>>>> org.jboss.logging.JBossLogManagerProvider >>>>> org.jboss.seam.solder.bean.defaultbean.DefaultBeanExtension$1 >>>>> org.jboss.seam.solder.util.collections.AbstractMultimap$KeySet$1 >>>>> org.jboss.logging.Log4jLogger >>>>> org.jboss.logging.JBossLogManagerLogger >>>>> >>>>>>> Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission accessDeclaredMembers) >>>> >>>> What exactly is the issue here? >>>> Reflection should still work on GAE. >>> Issue is related to the fact that the method >>> java.lang.Class.getGeneric* are not fully implemented on App Engine's >>> JDK. I think this is similar to >>> http://code.google.com/p/googleappengine/issues/detail?id=4250. >>>> >>>>> 4. weld-core >>>>> In InstantiatorFactory I have commented out adding >>>>> ReflectionFactoryInstantiator. It is not allowed to use >>>>> ReflectionFactory on GAE. Adding reflection factory should be check >>>>> programmatically before creating new instance in some if clause. >>>>> >>>>>>> java.lang.NoClassDefFoundError: sun.reflect.ReflectionFactory is a restricted class. Please see the Google App Engine developer's guide for more details. >>>>>>> at com.google.appengine.runtime.Request.process-609c29691be26e8f(Request.java) >>>>>>> at sun.reflect.ReflectionFactory.<clinit>(ReflectionFactory.java) >>>>>>> at java.lang.reflect.Method.invoke(Method.java:43) >>>>>>> at org.jboss.weld.util.reflection.instantiation.ReflectionFactoryInstantiator.<init>(ReflectionFactoryInstantiator.java:45) >>>> >>>> This looks like RFI should catch Throwable instead of Exception in ctor. >>>> >>>> And I haven't hit this. >>>> When does InstantiatorFactory get used? >> >> >> Yeah, "unproxyable" bean, which then needs JDK "hacks". >> Could that Wicket bean be changed, to be proxyable by default mechanism? >> > If only I knew which one it is. As I remember stack thread suggests > that it was interceptor or decorator with private constructor. >> >>> Maybe some class from wicket module initiates that. Full stacktrace is: >>> Uncaught exception from servlet >>> java.lang.NoClassDefFoundError: sun.reflect.ReflectionFactory is a >>> restricted class. Please see the Google App Engine developer's guide >>> for more details. >>> at com.google.appengine.runtime.Request.process-609c29691be26e8f(Request.java) >>> at sun.reflect.ReflectionFactory.<clinit>(ReflectionFactory.java) >>> at java.lang.reflect.Method.invoke(Method.java:43) >>> at org.jboss.weld.util.reflection.instantiation.ReflectionFactoryInstantiator.<init>(ReflectionFactoryInstantiator.java:45) >>> at org.jboss.weld.util.reflection.instantiation.InstantiatorFactory$1.<init>(InstantiatorFactory.java:41) >>> at org.jboss.weld.util.reflection.instantiation.InstantiatorFactory.<clinit>(InstantiatorFactory.java:37) >>> at org.jboss.weld.util.Proxies.getUnproxyableClassException(Proxies.java:228) >>> at org.jboss.weld.util.Proxies.getUnproxyableTypeException(Proxies.java:166) >>> at org.jboss.weld.util.Proxies.getUnproxyableTypesException(Proxies.java:191) >>> at org.jboss.weld.util.Proxies.isTypesProxyable(Proxies.java:180) >>> at org.jboss.weld.bean.ManagedBean.<init>(ManagedBean.java:328) >>> at org.jboss.weld.bean.ManagedBean.of(ManagedBean.java:293) >>> at org.jboss.weld.bootstrap.AbstractBeanDeployer.createManagedBean(AbstractBeanDeployer.java:239) >>> at org.jboss.weld.bootstrap.BeanDeployer.createBeans(BeanDeployer.java:156) >>> at org.jboss.weld.bootstrap.BeanDeployment.deployBeans(BeanDeployment.java:216) >>> at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:370) >>> at org.jboss.weld.environment.servlet.Listener.contextInitialized(Listener.java:205) >>> at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:548) >>> at org.mortbay.jetty.servlet.Context.startContext(Context.java:136) >>> at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1250) >>> at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517) >>> at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:467) >>> at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) >>> at com.google.net.rpc.impl.RpcUtil.runRpcInApplication(RpcUtil.java:437) >>> at com.google.net.rpc.impl.Server$RpcTask.runInContext(Server.java:573) >>> at com.google.tracing.TraceContext$TraceContextRunnable$1.run(TraceContext.java:448) >>> at com.google.tracing.TraceContext.runInContext(TraceContext.java:688) >>> at com.google.tracing.TraceContext$AbstractTraceContextCallback.runInInheritedContextNoUnref(TraceContext.java:326) >>> at com.google.tracing.TraceContext$AbstractTraceContextCallback.runInInheritedContext(TraceContext.java:318) >>> at com.google.tracing.TraceContext$TraceContextRunnable.run(TraceContext.java:446) >>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) >>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) >>> at java.lang.Thread.run(Thread.java:636) >>>> >>>>> I have not tested yet which solder features are working and which ones >>>>> not. In wicket page injection works as expected. >>>> >>>> Solder works for me, but I only use @Resource handling atm. >>>> >>>>> If you are interested in providing support for GAE, I think it would >>>>> be great to have this changes apply to master branch. Some of them >>>>> (especially 3 and 4) need some more development and propably support >>>>> from weld team. >>>> >>>> If you can provide some example / test, I'll definitely have a look at this. >>> I'm working on that application https://github.com/endpoint/widgetly. >>> Currently there is only integration stuff so you can treat it as test >>> case. >>> All of the changes I need to make I have done in separate branches in >>> my fork repositories: >>> Solder: https://github.com/smigielski/solder/tree/deployOnGAE >>> Wicket: https://github.com/smigielski/wicket/tree/deployOnGAE >>> Weld https://github.com/smigielski/core/tree/deployOnGAE >>> >>>> >>>> I'm playing with GAE for some JavaEE+GAE portability POC, >>>> I'll post about exactly what I'm doing asap -- probably around JBW time. >>>> >>>> -Ales >>>> >>>> >>> When I was writing that email I had forgotten about one more issue: >>> 5. solder-api >>> >>> In class LoggerProviders I have moved >>> final LogManager jdkLogManager = LogManager.getLogManager(); >>> into try-catch block. java.util.logging.LogManager is a restricted class. >> >> This one is already known, and the patch to logging and solder were already submitted. >> >> > _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev