On Mon, Apr 13, 2009 at 5:42 PM, Georg Ragaller <[email protected]> wrote:
> Although I don't know exactly what happens in qi4j internals, my rough > understanding says, that the restrictions should not be a no go, > since reflection is fully supported on own classes. So if the core does not > use reflection on other classes, it should work. > Perhaps the sticking point is really the JRE class whitelist. All the other > restriction are more related to architectural or configuration issues, I > think. Well, I can see 4 potential issues; 1. We are using some forbidden class/method. 2. They don't allow setAccessible() on Fields et al. 3. We generate sub-classes on the fly with ASM. They may no allow that. 4. Our use of generics is fairly extensive, and if their JVM is not Sun's, then there might be corner-cases which doesn't behave the same, i.e. Qi4j ends up clueless.. So, trying would be really important, but can't get an account at the moment. I'm asking around with friends at Google and see if they can dig up someone to ask for one. > Altogether, I'm personnally *not* really interested in using AppEngine (at > least at this time), so the main reason I pointed to it was, that it could > prove again (or not) qi4j's flexibility regarding the pluggable ES mechanism > and it could be attractive for others. > So it's really a 'nice to have' from my point of view. Ok, personally I see it much more strategically important. I have even started on a plugin for IDEA, where I can do, edit --> testLocally --> deploy for Qi4j applications. If you develop a Qi4j app for web, you should be a single click from deployment. And with zero cost, that sounds like a really neat deal. Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
