[seam-dev] Running weld + solder + wicket on GAE

Marek Śmigielski marek.smigielski at gmail.com
Fri Apr 22 16:41:45 EDT 2011


On Thu, Apr 21, 2011 at 1:29 PM, Ales Justin <ales.justin at gmail.com> 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.
>
>



More information about the seam-dev mailing list