"bil...@jb..." wrote :
| Besides the ammount of effort it would take to implement this, do you really think this would ever perform well? Not only do you have to analyze the class and create parallel java.lang.reflect datastrucutres (which takes an absorbent amount of time), but what if the component does dynamic class loading?
|
| Because of has, hasfield, and annotations, AOP needs a lot of the information of the structure of a class so I don't see much optimization that can be done here.
First, I'm not saying we do all the effort now, especially if we have known
performance problems. My concern (as I said earlier) is that it does not become
impossible, e.g. because we are locked into an api that requires the classes loaded.
Like you I develop iteratively, so the first implementation will be based on manifest
references (this jar needs this other jar) and package demands to capture
non-obvious dependencies.
| <deployment>
| <demand type="package">com.acme.blah</demand>
| etc.
|
this will solve most problems for the initial bootstrap, and force a full teardown
of the deployment and restart.
But there are other requirements (down the road)
that make this "belt and braces" approach undesirable.
1) Near seemless redeployment (redeploy in the background then cutover the gateway to the service, e.g. the jndi binding/socket or whatever)
2) Transactional redeploy (similar to 1 - but only do the cutover when all machines/services are sucessfully redeployed).
3) etc.
Fundamentally, it is being able to spot the difference between doing a full redeploy
because the classes changed (redeploy the jdbc driver) and an almost instantaneous cutover if you just change config (the datasource).
Although the jdbc driver is a bad example since you are hardly ever going to switch driver
versions on a running machine unless you are developing one.
Other more user orientated examples are not.
Finally, I don't necessarily need all the ClassInfo to do this, just the ability not to the load class.
We mainly went down the ClassInfo road because it gives an extended reflection
model that could be used by both AOP and MC. If it is bad, lets replace it with
something else.
Finally 2, I also don't believe that the performance problems are something that
cannot be overcome. The JDK does a pretty good job at analysing byte code
(probably doing more work than javassist) in a performant fashion.
This is all moot for 4.0.3 since the JMX MC will be handling classloading.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875782#3875782
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875782
|
