I have managed to deploy and successfully test simple injection of
weld-servlet, seam-wicket and solder module to GAE. This task involves
making some modifcations in all of this modules.
In AbstractJndiBeanManagerProvider I have added catch for
NoClassDefFoundError just after NamingException. GAE can't initialize
>> java.lang.NoClassDefFoundError: Could not initialize class com.google.apphosting.runtime.security.shared.stub.javax.naming.InitialContext
I have added service ServletContextBeanManagerProvider which resolves
BeanManager from ServletContext as JNDI based providers does not work.
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:
>>Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission accessDeclaredMembers)
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)
I have not tested yet which solder features are working and which ones
not. In wicket page injection works as expected.
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.
I'm gonna create a lot of binding object for each social services in Social, and a remark from Marek Schmidt made me wonder if it could be a good choice to create a specific submodule (i.e. jar) for each service ?
I could, haven't yet though.
On Mon, Apr 11, 2011 at 12:26, José Rodolfo Carrijo de Freitas <
> Nice, are you going to post in TSS ? or another big it news website?
> *De:* seam-dev-bounces(a)lists.jboss.org [mailto:
> seam-dev-bounces(a)lists.jboss.org] *Em nome de *Jason Porter
> *Enviada em:* sábado, 9 de abril de 2011 15:08
> *Para:* Shane Bryzak
> *Cc:* seam-dev(a)lists.jboss.org
> *Assunto:* Re: [seam-dev] Seam module spotlight series
> Attached is the markdown file for the first entry.
> On Fri, Apr 1, 2011 at 20:36, Shane Bryzak <sbryzak(a)redhat.com> wrote:
> I'd like to start up a weekly Seam module spotlight. Basically, each
> week I'd like one of you to write up an article that we can publish on
> in.relation.to that shows off the best features of your module.
> Preferably the article would be use-case centric, as opposed to the
> feature-centric style that we generally write with in the reference
> documentation. For example, if I was writing a blog post about the
> persistence module I would make the point that if you're writing POJO
> beans to implement your business layer that I would not have transaction
> support by default, and that is where the transaction features of the
> persistence module come in. I'd also explain how it could be useful in
> other container environments, such as Tomcat or even Java SE.
> This style of writing is more likely to get your readers to a point
> where they understand why your module is as cool as we say it is, as
> they can relate its coolness in terms of real life use cases. Whereas
> explaining things from a feature point of view might leave some confused
> as to how they can actually *use* that feature in their own projects.
> Anyway, I'm looking for a brave volunteer to go first. Ideally we'd get
> the first spotlight article published by the end of next week (before
> the 9th) so that should leave enough time to put together an informative
> seam-dev mailing list
> Jason Porter
> Software Engineer
> Open Source Advocate
> Author of Seam Catch - Next Generation Java Exception Handling
> PGP key id: 926CCFF5
> PGP key available at: keyserver.net, pgp.mit.edu
Open Source Advocate
Author of Seam Catch - Next Generation Java Exception Handling
PGP key id: 926CCFF5
PGP key available at: keyserver.net, pgp.mit.edu
Is there any way in Seam 3 or CDI itself to list active beans in all
scopes for debug purposes? I remember that it was debug page in Seam 2
with such functionality. If it isn't available, have you any
suggestions about the way of resolving list of beans either in all
scopes or in particular scope?
I'll need to dynamically create scoped CDI beans. I guess I have to use the @New qualifier but as I didn't found example in other modules (was looking for the Seam Groovy module port), I was wondering if it's a good practice. Feedback or example are welcome.
in Seam social I created bean to deal with social network. I named those Bean with "Handler" suffix : i.e. TwitterHandler. I choose this over "Service" or "Controller" but as there will be other Seam module dealing with high level functional services, I prefer check this naming convention with you. Sharing the same naming convention across modules to have something homogenous is something important.
Twitter ; http://twitter.com/antoine_sd
LinkedIn : http://fr.linkedin.com/in/antoinesabotdurand