>> 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.