Menu
▾
▴
jboss-dev-forums
|
From: <ad...@jb...> - 2005-04-26 17:24:07
|
I'm confused again. We always seem to be on completely different wavelengths :-) 1) I already had a MAP in the original implementation, but changed it to Annotation since we agreed that all config will come from annotations (as opposed to ad hoc invocation payload) and this would make it easier for construct/configure from xml. In fact, there is an open issue on whether the MC should just use AOP's annotation metadata model. There is even a test in the jboss-aspects module using AbstractAnnotationMetaData: http://cvs.sourceforge.net/viewcvs.py/jboss/jboss-aspects/src/tests/org/jboss/test/aspects/microcontainer/test/InterceptorTestCase.java?rev=1.1&view=markup Did you know that about FeatureMetaData or even the tasks I created after our Boston meetings? http://cvs.sourceforge.net/viewcvs.py/jboss/microkernel/src/main/org/jboss/beans/metadata/plugins/AbstractFeatureMetaData.java?r1=1.4&r2=1.5 http://jira.jboss.com/jira/browse/JBMICROCONT-18 2) It is too late to pass this in the join point constructor isn't it? I need to tell JBoss/AOP about the annotations to find out what they mean in terms of dependencies???? This cannot be done at the construction stage, it must be done during DESCRIBE. Otherwise, the MC/AOP integration serves no purpose. | | /** | * Get a constructor join point | * | * @param constructorInfo the constructor info | * @param metadata // THIS IS TOO LATE | * @return the constructor join point | * @throws JoinpointException when no such constructor | */ | ConstructorJoinpoint getConstructorJoinpoint(ConstructorInfo constructorInfo, Map metadata) throws JoinpointException; | Maybe you have simplied this or found a way around the problem? But it seems pretty fundamental to me? 3) The ClassAdapter should just be a bridge to JBoss/AOP or reflection model. That is its only purpose. i.e. which implementation should the MC use. To repeat the only reasons for the reflection model are: a) I need to be convinced that JBoss/AOP (really javassist) can be used in all environments b) AOP's ClassAdapter wasn't finished but I needed to work on other things If (a) can be satisfied, (i.e. in all circumstances no matter what the security/memory restrictions are JBoss/AOP/Javasssit can be used) then I don't have any problem with predecating JBoss/MC on JBoss/AOP and the need for an abstract integration "ClassAdapter" disappears. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875471#3875471 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875471 |
|
From: <bil...@jb...> - 2005-04-27 02:39:14
|
"ad...@jb..." wrote : I'm confused again. We always seem to be on completely different wavelengths :-) | | 1) I already had a MAP in the original implementation, but changed it to Annotation | since we agreed that all config will come from annotations (as opposed to ad hoc | invocation payload) | THis metadata I added has nothing to do with ad hoc invocation payloads. The metadata is needed by the ClassAdapter to resolve aspect dependencies and for the ConstructorJoinpoint so that it can either create a proxy or modify the object instance's InstanceAdvisor. anonymous wrote : | and this would make it easier for construct/configure from xml. | JBoss AOP already has an annotation override facility. What I added allows MC to take advantage of this facility without also tying MC to this facility. anonymous wrote : | In fact, there is an open issue on whether the MC should just use AOP's annotation | metadata model. | This sure would make things easier. anonymous wrote : | There is even a test in the jboss-aspects module using AbstractAnnotationMetaData: | http://cvs.sourceforge.net/viewcvs.py/jboss/jboss-aspects/src/tests/org/jboss/test/aspects/microcontainer/test/InterceptorTestCase.java?rev=1.1&view=markup | If you want to fully redo what JBoss AOP already does, be my guest, but count me out... anonymous wrote : | Did you know that about FeatureMetaData or even the tasks I created after our Boston | meetings? | http://cvs.sourceforge.net/viewcvs.py/jboss/microkernel/src/main/org/jboss/beans/metadata/plugins/AbstractFeatureMetaData.java?r1=1.4&r2=1.5 | http://jira.jboss.com/jira/browse/JBMICROCONT-18 | Sure saw it, but again, didn't want to rewrite the entire JBoss AOP annotation facility. anonymous wrote : | 2) It is too late to pass this in the join point constructor isn't it? I need to tell JBoss/AOP | about the annotations to find out what they mean in terms of dependencies???? | You mean for dependencies like the SecurityDomain example? I don't see why you need to tell JBoss AOP these dependencies. JBoss AOP doesn't care about dependencies. It really depends on who is analyzing the annotations for the @DependsAttribute annotation (or whatever it will be). If it is the microcontainer, then no, it is not too late as the microcontainer can just add these to the dependency list itself. anonymous wrote : | This cannot be done at the construction stage, it must be done during DESCRIBE. | Otherwise, the MC/AOP integration serves no purpose. | | | | | | /** | | * Get a constructor join point | | * | | * @param constructorInfo the constructor info | | * @param metadata // THIS IS TOO LATE | | * @return the constructor join point | | * @throws JoinpointException when no such constructor | | */ | | ConstructorJoinpoint getConstructorJoinpoint(ConstructorInfo constructorInfo, Map metadata) throws JoinpointException; | | | | Maybe you have simplied this or found a way around the problem? But it | seems pretty fundamental to me? | Did you see that I added passing metadata to ClassAdapter.getDependencies()? getConstructorJoinpoint needs to know about annotation overrides, mixin definitions, etc... because the ConstructorJoinpoint itself needs to know about this information so that it knows wheter or not to create a proxy (if the class is not weaved) or to interact with the per-instance InstanceAdvised interface. If you do not pass in these annotation overrides into the ConstructorJoinpoint, then the ConstructorJoinpoint does not have the exact information it needs to make its decisions. anonymous wrote : | To repeat the only reasons for the reflection model are: | a) I need to be convinced that JBoss/AOP (really javassist) can be used in all environments | THis idea that everything has to work in all environments with the 1st iteration or even the first release of MC, MC+AOP is just stupid. Iterate! I've taken out the Javassist requirement for the MC /AOP integration. I've posted how/why on architecture council email list, I'll repost here. Load-time AOP probably just will not work on all environments. AOPC precompilation should work in all environments because Javassist is take out of the equation. If you have look at my MC/AOP integration code and tests you'll see that it supports a proxy based model. Currently proxies are created by Javassist for performance and flexibility reasons, but this could be changed to be fully java.lang.reflect.Proxy based if you so desire. anonymous wrote : | b) AOP's ClassAdapter wasn't finished but I needed to work on other things | AOP's ClassAdapter is not fully finished. I'll talk about this in another post. anonymous wrote : | If (a) can be satisfied, (i.e. in all circumstances no matter what the security/memory | restrictions are JBoss/AOP/Javasssit can be used) then I don't have any problem | with predecating JBoss/MC on JBoss/AOP and the need for an abstract | integration "ClassAdapter" disappears. (a) cannot uniformily be solved by JBoss AOP unless AOPC precompilation is a requirement. If you dislike AOPC precompilation as a requirement, then you just have to deal with less AOP funtionality and use proxies. JBoss AOP can support this and does partially support it now. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875526#3875526 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875526 |
|
From: <ad...@jb...> - 2005-04-27 19:59:38
|
Ok, let's deal with a fundamental problem first. The MC does not necessarily use a ConstructorJoinPoint. It could use a factory to create the object. See the ConstructorMetaData. The idea of the ClassAdapter was that it would use this as a context for overrides on the object being constructed. The only other mechanism would be to pass the override context under the wire in a thread local. Of course we could disallow factories as a mechanism to construct objects, it certainly is a part of the javabean spec. But this limits the number of object heirarchies that can be deployed using the MC. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875643#3875643 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875643 |
|
From: <ad...@jb...> - 2005-04-27 20:01:51
|
The reason for knowing about the SecurityDomain is a fundamental difference in the deployment strategies of AOP vs MC In AOP if the advice is not deployed it is not included in the stack. If a depdendency of the advice is not deployed you find out after requests are being processed with a runtime exception. In the MC if the advice and its dependencies are not installed the object is not created and the user is told to deploy the missing dependency. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875644#3875644 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875644 |
|
From: <ad...@jb...> - 2005-04-27 20:08:51
|
I don't mind the MC using the AOP annotation metadata format. My only concern would be the potential in future for an annotation to include data that also requires DI. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875646#3875646 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875646 |
|
From: <ad...@jb...> - 2005-04-27 20:10:28
|
"ad...@jb..." wrote : I don't mind the MC using the AOP annotation metadata format. My only concern would be | the potential in future for an annotation to include data that also requires DI. And that the AOP version has a notion of instance??? I only want the annotation to apply to that object not all future objects of the same class. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875648#3875648 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875648 |
|
From: <ad...@jb...> - 2005-04-27 20:13:43
|
"bil...@jb..." wrote : | THis idea that everything has to work in all environments with the 1st iteration or even the first release of MC, MC+AOP is just stupid. Iterate! | | + others | At the time this was an important requirement because of the need for jmx/mc interopability/backwards compatibilty. This is less important now that JBoss5 will not be release of this software. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875651#3875651 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875651 |
|
From: <ad...@jb...> - 2005-04-27 20:47:48
|
"ad...@jb..." wrote : | The idea of the ClassAdapter was that it would use this as a context for overrides | on the object being constructed. | Anticipating you saying this contradicts my description of the ClassAdapter as just a bridge. Yes the ClassAdapter is a bridge, but that was why I had ClassAdapter.getInstanceAdapter() that created a context from which I retrieved joinpoints that knew about the context, i.e. annotation overrides. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875660#3875660 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875660 |
|
From: <bil...@jb...> - 2005-04-28 00:19:51
|
anonymous wrote :
| Ok, let's deal with a fundamental problem first.
|
| The MC does not necessarily use a ConstructorJoinPoint.
| It could use a factory to create the object. See the ConstructorMetaData.
|
|
The AOP container needs to intercept the allocation of the bean by the MC. Whether this is done by a constructor or factory method, it doesn't matter. AOP needs to intercept allocation so that it can put a proxy in place or initialize the InstanceAdvisor (depending whether the class is aspectized or not).
What I think we should do is ditch the ClassAdapter stuff and just have an AspectAdapter. An AspectAdapter should be created per bean. This would require a rewrite of your MC because allocation information and the ClassAdapter stuff is embedded within the BeanInfo class which is cached on a per-class basis.
I think the AspectAdapter interface should be as follows in live within the kernel/ module:
| public interface AspectAdapterFactory {
| AspectAdapter createAspectAdapter(Class clazz, BeanMetaData metadata);
| }
|
Yes, AOP Requires the java.lang.Class. Again, I refuse to use ClassInfos because it would require too much refactoring to JBoss AOP and creating ClassInfos with Javassist, is just way too slow. I have no desire to refactor Javassist as well to make it faster. I think you are going way overboard with dependency management here. Requiring too much work for too little reward.
The AspectAdapter interface might look something like this:
| public interface AspectAdapter {
| public List getDependencies();
| public ConstructorJoinpoint getConstructorJoinpoint(ConstructorInfo);
| public MethodJoinpoint getFactoryJoinpoint();
| public FieldGetJoinpoint getFieldGetJoinpoint(FieldInfo);
| public FieldSetJoinpoint getFieldSetJoinpoint(FieldInfo);
| public MethodJonipoint getMethodJoinpoint(MethodInfo);
| }
|
For JBoss AOP at least, the getMethodJoinpoint would not be needed. FieldGet/FieldSet are needed because JBoss AOP wraps field access in a static method call. A separate getFactoryJoinpoint and getConstructorJoinpoint is needed, because again, JBoss AOP needs to be able to intercept allocation to create a proxy or to interact with the aspectized class's object instance's InstanceAdvisor.
This is going to require a bunch of refactoring to MC because currently the classadapter is hidden by BeanInfos.
Bill
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875686#3875686
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875686
|
|
From: <ad...@jb...> - 2005-04-28 00:53:09
|
It will take me a while to digest your proposal. I don't see the meat of it (how it could possibly work) at the moment. At first blush, this looks like my original proposal, which was that the MC would push all the metadata to the AspectManager, but we decided against that solution because 1) it would require the MC understanding all the point cut expressions, etc. i.e. understanding the cross cutting. 2) users can still deploy using jboss-aop.xml which the MC wouldn't know about. Instead, we decided on the query approach where the MC asks the AOP layer "what would it mean if I created an instance of this object" during the describe stage. Correct me if I have misunderstood. anonymous wrote : | This is going to require a bunch of refactoring to MC because currently the classadapter is hidden by BeanInfos. | I don't mind refactoring, especially if it simplifies the problem. I don't see why the ClassAdapter inside the BeanInfo creates a problem. The BeanInfo is just a description of the class after AOP has played with it and it is per ClassAdapter (which could be instance level) not per Class. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875688#3875688 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875688 |
|
From: <ad...@jb...> - 2005-04-28 00:57:39
|
On the joinpoint model:
This is serving more than just a dialogue between the MC and AOP.
It is acting as a cache for the reflection style objects.
Resolving reflection objects is much more expensive than using them
which is why the current EJB/JMX containers preresolve these objects.
They are also used by the Bus/Detyped invocations:
| public interface KernelBus extends KernelObject
| {
| /**
| * Invoke an operation
| *
| * @param name the name of the object
| * @param joinPoint the join point
| * @return the result
| * @throws Throwable for any error
| */
| Object invoke(Object name, TargettedJoinpoint joinPoint) throws Throwable;
| }
|
This goes back to the "do we need to support a reflection implementation" question.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875689#3875689
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875689
|
|
From: <ad...@jb...> - 2005-04-28 01:02:06
|
"bil...@jb..." wrote : I think you are going way overboard with dependency management here. | I think this goes to heart of the disagreement. My vote is for using picocontainer with limited ability to support hot-deployment or correctly startup a disparate group of loosy couple modules. Leaving me to get on with doing something more useful than arguing about DI. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875691#3875691 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875691 |
|
From: <ad...@jb...> - 2005-04-28 01:05:14
|
"ad...@jb..." wrote : "bil...@jb..." wrote : I think you are going way overboard with dependency management here. | | | | I think this goes to heart of the disagreement. | | My vote is for using picocontainer with limited ability to support hot-deployment | or correctly startup a disparate group of loosy couple modules. | | Leaving me to get on with doing something more useful than arguing about DI. | A joke, but like most good jokes it is not far from the truth. :-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875692#3875692 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875692 |
|
From: <bil...@jb...> - 2005-04-28 01:12:34
|
anonymous wrote :
| The reason for knowing about the SecurityDomain is a fundamental difference
| in the deployment strategies of AOP vs MC
|
| In AOP if the advice is not deployed it is not included in the stack.
| If a depdendency of the advice is not deployed you find out after requests are
| being processed with a runtime exception.
|
I don't think you understand how I am doing this AOP/MC integration.
When the AOP deployer sees an Aspect declaration, it will create a GenericBeanFactory and install it into the Microconatiner. It will also register AOP specific metadata about the Aspect into the AspectManager.
When a binding is defined, the AOP Deployer creates an InterceptorFactory and registers the metadata for binding the advice/aspect to the class. This InterceptorFactory has a reference to the Kernel. When a Class is statically initialized, it tries to create advice chains. This is when the InterceptorFactory tries to lookup the GenericBeanFactory.
anonymous wrote :
| In the MC if the advice and its dependencies are not installed the object is not created
| and the user is told to deploy the missing dependency.
|
And this works, so what is the problem? ClassAdapter.getDependencies() is currently called before class static initialization and the aspect dependencies propagated. Did you see that I implemented and tested this?
The SecurityDomain example is a different example. This is because knowledge of the dependency is hidden in the annotations. So, I thought our agreement was that this annotation would have a @Dependency annotation on it:
| @Dependency(attribute="value")
| public @Interface SecurityDomain {
| String value();
| }
|
Either the MC or AOP is gonna have to look at every single annotation attached to the class (and superclass) for this @Dependency annotation and add it to the BeanMetaData dependency list. Correct? I'm fine with adding this to the AspectAdapter.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875695#3875695
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875695
|
|
From: <bil...@jb...> - 2005-04-28 01:17:42
|
"ad...@jb..." wrote : "bil...@jb..." wrote : I think you are going way overboard with dependency management here. | | | | I think this goes to heart of the disagreement. | | My vote is for using picocontainer with limited ability to support hot-deployment | or correctly startup a disparate group of loosy couple modules. | | Leaving me to get on with doing something more useful than arguing about DI. | The "overboard" I'm talking about is publishing dependencies before the class is loaded so that class loading is aware of aspect dependencies as well. I think publishing aspect dependencies after the class is loaded and before class static initialization, will work just fine without to much disruption in so many codebases. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875697#3875697 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875697 |
|
From: <bil...@jb...> - 2005-04-28 01:24:52
|
"ad...@jb..." wrote : On the joinpoint model: | | This is serving more than just a dialogue between the MC and AOP. | It is acting as a cache for the reflection style objects. | Then cache these objects. AOP still has to intercept bean allocation. I can't get around that. Also resolving dependencies also needs to be aware of additional annotations and metadata that is attached to the bean. anonymous wrote : | | Resolving reflection objects is much more expensive than using them | which is why the current EJB/JMX containers preresolve these objects. | Yes, AOP caches the same information as well to speed up invocations. Bill View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875698#3875698 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875698 |
|
From: <ad...@jb...> - 2005-04-28 01:51:56
|
"bil...@jb..." wrote : I don't think you understand how I am doing this AOP/MC integration. | It is more likely I don't understand your own description of what you have done :-) anonymous wrote : anonymous wrote : | | In the MC if the advice and its dependencies are not installed the object is not created | | and the user is told to deploy the missing dependency. | | | | And this works, so what is the problem? ClassAdapter.getDependencies() is currently called before class static initialization and the aspect dependencies propagated. Did you see that I implemented and tested this? | Yes. anonymous wrote : | The SecurityDomain example is a different example. This is because knowledge of the dependency is hidden in the annotations. | I thought you had started arguing that this could not be done? anonymous wrote : | So, I thought our agreement was that this annotation would have a @Dependency annotation on it: | Yes. anonymous wrote : | Either the MC or AOP is gonna have to look at every single annotation attached to the class (and superclass) for this @Dependency annotation and add it to the BeanMetaData dependency list. Correct? I'm fine with adding this to the AspectAdapter. | I don't think it matters who does it as long as it gets done. I thought we agreed that it would be done by MC since it could be potentially looking at classes that AOP doesn't care about. The main issue now I think is how the MC gets hold of the annotations if there is no ClassInfo. It looks like it falling back on reflection. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875701#3875701 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875701 |
|
From: <bil...@jb...> - 2005-04-28 01:53:56
|
"ad...@jb..." wrote : It will take me a while to digest your proposal. | I don't see the meat of it (how it could possibly work) at the moment. | But, don't you see it already works? The only situation I didn't handle was the factory. The AspectAdapter solves this. anonymous wrote : | At first blush, this looks like my original proposal, which was that the MC would | push all the metadata to the AspectManager, but we decided against that solution | because | I thought your original proposal was to write your own AOP abstraction SPI that AOP had to somehow fit into, or to write your own "lightweight" AOP model to support all the JMX stuff. anonymous wrote : | 1) it would require the MC understanding all the point cut expressions, etc. | It doesn't. Metadata would be created like any other attribute, map, list, etc...You'd be creating JBoss AOP metadata instances like you would with any other embedded bean attribute. The MC doesn't know about anything, it is just creating a bunch of beans and attaching them to the BeanMetaData instance. It is up to the AspectAdapter to to make sense of the metadata, not the MC. anonymous wrote : | i.e. understanding the cross cutting. | 2) users can still deploy using jboss-aop.xml which the MC wouldn't know about. | And I assumed from the beginning that users would deploy using jboss-aop.xml. It would be the job of the AOP Deployer to interact with the MC and create the required extra metadata and bean registrations. This is actually how I have it implemented in the tests. anonymous wrote : | Instead, we decided on the query approach where the MC asks the AOP | layer "what would it mean if I created an instance of this object" during the | describe stage. | And again, this is how I have it implemetned currently. What is missing is factory support. Again, AOP needs to intercept construction for any bean. It needs BeanMetadata (the annotation overrides and per-bean aspect bindings) anonymous wrote : | I don't see why the ClassAdapter inside the BeanInfo creates a problem. | The BeanInfo is just a description of the class after AOP has played with it | and it is per ClassAdapter (which could be instance level) not per Class. Then come up with another interface where AOP can intercept bean allocation (whether it be by a constructor or a factory) and have knowledge of Beanmetadata. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875702#3875702 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875702 |
|
From: <ad...@jb...> - 2005-04-28 01:55:54
|
anonymous wrote : | The "overboard" I'm talking about is publishing dependencies before the class is loaded so that class loading is aware of aspect dependencies as well. | | I think publishing aspect dependencies after the class is loaded and before class static initialization, will work just fine without to much disruption in so many codebases. | Ok, we will have to disagree on this one (but not about the disruption). Would you care to make a wager on whether this problem ever comes up on the forums or as a support case? :-) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875703#3875703 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875703 |
|
From: <ad...@jb...> - 2005-04-28 02:03:42
|
"bil...@jb..." wrote :
| I thought your original proposal was to write your own AOP abstraction SPI that AOP had to somehow fit into, or to write your own "lightweight" AOP model to support all the JMX stuff.
|
That was actually a later argument on whether we should support other peoples
invocation models which we rejected.
The JMX stuff was about mapping jmx invocations
JMXGetAttribute("UpperCaseStyle") to AOPMethodInvocation("getUpperCaseStyle");
which we also rejected as too complicated and unnecessary since a DynamicMBean
can do this without the need for JMXGetAttribute objects.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875704#3875704
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875704
|
|
From: <bil...@jb...> - 2005-04-28 02:03:44
|
"ad...@jb..." wrote : anonymous wrote : | | The "overboard" I'm talking about is publishing dependencies before the class is loaded so that class loading is aware of aspect dependencies as well. | | | | I think publishing aspect dependencies after the class is loaded and before class static initialization, will work just fine without to much disruption in so many codebases. | | | | Ok, we will have to disagree on this one (but not about the disruption). | Would you care to make a wager on whether this problem ever comes up on the forums | or as a support case? :-) I think the price is going to be too high, both in performance hits and development cycles, which is why I am not interested in solving this problem. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875705#3875705 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875705 |
|
From: <bil...@jb...> - 2005-04-28 02:07:22
|
"ad...@jb..." wrote : I don't mind the MC using the AOP annotation metadata format. My only concern would be | the potential in future for an annotation to include data that also requires DI. An interesting use case, but I have no desire to rewrite an entire annotation override facility just to support this. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875707#3875707 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875707 |
|
From: <ad...@jb...> - 2005-04-28 02:12:43
|
"bil...@jb..." wrote : | Then come up with another interface where AOP can intercept bean allocation (whether it be by a constructor or a factory) and have knowledge of Beanmetadata. | With your latest qualifications the AspectAdapter[Factory] sounds like it will work. But there is a big assumption that class resolution and/or not yet deployed classes isn't going to be cause problem. I just want to confirm the following lifecycle. It is nearly equivalent to the original proposal but with different objects. MC DESCRIBE: Use AspectAdapterFactory to get an AspectAdapter for the Class and its metadata. Use getDependencies to retrieve all dependencies (whether this is just what AOP thinks is important and MC needs to do extra work on top is unimportant) MC INSTANTIATE: Use AspectAdapter to get the joinpoint and dispatch the construct/factory request. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875708#3875708 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875708 |
|
From: <ad...@jb...> - 2005-04-28 02:14:36
|
"ad...@jb..." wrote : | Use AspectAdapterFactory to get an AspectAdapter for the Class and its metadata. | metadata == BeanMetaData including annotations. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875710#3875710 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875710 |
|
From: <ad...@jb...> - 2005-04-28 02:20:08
|
"ad...@jb..." wrote : | But there is a big assumption that class resolution and/or not yet deployed classes | isn't going to be cause problem. | I think this is virtually certain by the way, but mostly in use cases that involve either are own core services or where one top level deployment is referencing another and hot deployment is required. In fact, without this knowledge, automatic redeployment of related top level deployments because they share a classloader space becomes very difficult, if not impossible. And we are back with the all the stupid forums questions about ClassCasts, etc. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875711#3875711 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875711 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X