Please submit to the Weld JIRA. On 10 May 2011, at 08:33, Marek Śmigielski wrote:
> 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/e6d40d736710dded13738d83eb1f8d8ab2a25cf1. > > 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 > <[email protected]> wrote: >> On Thu, Apr 21, 2011 at 1:29 PM, Ales Justin <[email protected]> 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 > [email protected] > https://lists.jboss.org/mailman/listinfo/seam-dev _______________________________________________ seam-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/seam-dev
