-
1. Container
adrian.brock Jan 26, 2005 7:03 PM (in response to adrian.brock)Roadmap for the Container:
We want to define/agree the spi
The implementation/plugins are just what I had for for my prototype and are
included for reference.
1) Replace the container abstraction with the jboss-aop abstraction
which is more feature rich.
This is not the aop implementation which will remain in the jboss-aop.
2) Keep the BeanInfo abstraction as this is used by the microcontainer
(remember not all beans will have a container)
3) Decide how much of my current prototype of a join point model is relevent
and whether it is correct
4) Produce JIRA tasks once it is agreed or JFDI
Keep in mind that the abstraction should be flexible enough to be
implemented a proxy container, if the aop container cannot be run in a certain environment.
So actually the requirement is that a container should be available in all environments,
J2ME, applet, A.N.Other app server etc.
Running with the more limited proxy container may mean some features cannot be
implemented, e.g. field interception. -
2. Re: Container abstraction
bill.burke Jan 26, 2005 7:07 PM (in response to adrian.brock)FYI, JBoss AOP can be a proxy-container. I do this with EJB3.
-
3. Bean Info
adrian.brock Jan 26, 2005 7:14 PM (in response to adrian.brock)Roadmap for Bean Info:
The purpose of the BeanInfo is to provide the same features as the java.beans
package, except for the same reason that JMX introduced its own metadata
java.beans has a fundamental problem with its dependency on AWT in some places.
Hence it is not available in all environments.
1) Agree the BeanInfo abstraction
2) Decide whether javassist would be a better/alternate implementation (does it work
in all environments)
3) Agree missing features like the ability to define java.beans has to describe a
bean from a descriptor class
4) WRT (3), annotations would seam to me to be a better mechanism
5) Include annotations in the BeanInfo abstraction
6) Should we add support for redefining requests like constructor -> factory,
e.g. the microcontainer thinks it is doing new Bean() but it is actually doing
BeanFactory.createBean() or as these better left as container aspects?
Current Known Issues:
1) The introspection implementation is very agressive in that it will traverse the
all the class references when asked for information. A more lazy implementation
is required.
2) How to avoid this information using too much memory - e.g. are descriptions
necessary, if so can they be lazy loaded using I18N when required? -
4. Re: Container abstraction
adrian.brock Jan 26, 2005 7:17 PM (in response to adrian.brock)"bill.burke@jboss.com" wrote:
FYI, JBoss AOP can be a proxy-container. I do this with EJB3.
Yes, but does it work in all environments and what is the footprint with
jboss-aop using javassist, trove, etc.
If you can show me jboss-aop's proxy container working inside
1) j2me,
2) inside an ejb/web container of another appserver with a security manager installed
3) inside an applet
then we have no need to write an old fashioned proxy container like the prototype
BeanContainer -
5. Re: Container abstraction
bill.burke Jan 26, 2005 7:38 PM (in response to adrian.brock)We're supposed to be unifying things here. To do proxies, you need dynamic class creation. period. If you're just using java.lang.reflect.Proxy, you also need reflection as well.
Please state your concerns with:
1) footprint. I only use a few classes from jboss-common. Trove can be removed. Oswego cannot unless we switch to JDK5 as a base. QDox is just for the annotation compiler. Javassist cannot be removed as it is used to dynamically create classes. If classes cannot be dynamically created, then java reflection is needed. You'll have the same issue
2) security managers. Do you mean a security manager that disallows reflection or setAccessible(true)?
Please, let's not put any effort into writing a competing Interceptor model. We have enough to do as it is. -
6. Re: Container abstraction
adrian.brock Jan 27, 2005 11:07 AM (in response to adrian.brock)We are unifying the spi not the implementation. An interceptor doesn't care wether
it woven in through byte code manipulation or behind a proxy.
1a) My question was what is the footprint. My concern is that the size of the jars
if we are going to run on a system with limited space.
Most of jboss-common and concurrent are not used. These jars could
be very easily trimmed for a limited environment.
1b) java.lang.reflect.Proxy works in those environments. Yes you have to use
reflection (which means some features will not be available as I said).
2) I mean where you don't have control of the security policy.
These environments limit you to performing operations like classloading and reflection on
co-deployed classes (same classloader - or a child classloader if you are allowed to
create such a thing).
Certainly things like modifying accessibility or byte code manipulation won't be allowed. -
7. Re: Container abstraction
adrian.brock Jan 27, 2005 11:08 AM (in response to adrian.brock)My real concern is the unification.
The argument about the proxy is best resolved through the "suck it and see" approach. -
8. Re: Container abstraction
adrian.brock Jan 27, 2005 1:27 PM (in response to adrian.brock)I've refactored the core part of the bean configurator into the container module
so you can see how the microcontainer is using the BeanInfo/JoinPoint model.
See org.jboss.beans.info.config