jboss-dev-forums — The jboss development forum posts

[Jboss-dev-forums] [Design of Mail Services] - Howto add a page/add a portlet admin

[glarenzie <nu...@jb...>]

Guys,
          I must really be missing something.  I read every powerpoint, pdf, etc. and I have no idea how to add a portlet to the portal, edit the permissions and view it in the portal.  I have no trouble creating the war file and copying it to the default deploy folder.  I can not find an admin portlet that will let me create instances of my portlet and assign permissions to it.  I would also like to add a page.  Maybe because my experience with portals is BEA and epicentric i am blind to how to administer and config this portal.  I think documentation from an admin perspective would be very helpful.  Any help with htis would be greatly appreciated!

Grant



View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875799#3875799

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875799

[Jboss-dev-forums] [Design of JBoss internal QA (Test Suite)] - Re: Version compatibility tests

[<sco...@jb...>]

A test that requires jboss.jar either is not an external client test (and MetaDataUnitTestCase is not an external client test that should be run in this compatibility testsuite), or it indicates a problem with the definition of the client jars.

Every unit test in this compatibility test run should be able to run using only the jars in the client directory of the dist.


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875798#3875798

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875798

[Jboss-dev-forums] [Design of JBoss internal QA (Test Suite)] - Re: Version compatibility tests

[<cle...@jb...>]

This is almost done, I'm just validating it before I commit the code.

I have only one consideration. Some of the tests are requiring jboss.jar.

As jboss.jar has all the classes contained into jboss-client.jar I'm not sure if I could add jboss.jar in the classpath for this tests as well.

I don't know, it looks like some of these classes contained into jboss.jar should be present in jboss-client.jar as well, what would represent some point to be fixed.

For example, org.jboss.test.client.test.MetaDataUnitTestCase requires org/jboss/metadata/ClientMetaData which is not represent into jboss-client.jar

Any thoughts Scott? 


Clebert

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875794#3875794

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875794

[Jboss-dev-forums] [Design of JBoss Eclipse IDE (dev)] - Lack of resource bundle for base : javax.servlet.http.LocalS

[Masoud_Omidvar <nu...@jb...>]

Dears,

Recently, I try to use StrutsTestCase mockup to test some units. I try to use JBoss-IDE, but, unfortunately, servlet-api.jar which is placed in %Eclipse_Home%/plugins/org.jboss.ide.eclipse.jdt.j2ee.core_1.5.0.m1 does not contain any resource bundle. I have a suggestion, can you  replace it with JBoss javax.servlet.jar?

Cheers,
Masoud.



View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875792#3875792

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875792

[Jboss-dev-forums] [Design of JBossXB] - Re: POJO Schema parsing

[<ad...@jb...>]

"ale...@jb..." wrote : I would like to see what you are doing. Could you post/send me the code? What kind of warnings? 

I'll try to reproduce the problem in the testsuite. I was definitley getting a null object
back without the schema.

The issues with the warnings is not so much that they are appear (though it is
undue noise), more that when the schema has a real url (http://jboss.com/etc)
it will be doing network requests that might not work behind a firewall.

I'll start a new thread on schema usage (what Scott and I discussed before)
when I've looked a bit deeper into your current implementation - so I have
a more informed opinion :-)

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875791#3875791

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875791

[Jboss-dev-forums] [Design the new POJO MicroContainer] - Re: AOP/Metadata integration config

[<ad...@jb...>]

Incidently, I would prefer the AspectAdapterFactory had a similar api to the others
in the container model:


  | public interface ClassAdapterFactory
  | {
  |    ClassAdapter getClassAdapter(String name, ClassLoader cl) throws ClassNotFoundException;
  |    ClassAdapter getClassAdapter(Class clazz);
  | }
  | 

Then the underlying implementation can choose whether it actually needs to load
the class on the first method.
i.e. whether classloading is required is then a quality of implementation detail.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875783#3875783

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875783

[Jboss-dev-forums] [Design the new POJO MicroContainer] - Re: AOP/Metadata integration config

[<ad...@jb...>]

"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

[Jboss-dev-forums] [Design the new POJO MicroContainer] - Re: AOP/Metadata integration config

[<bil...@jb...>]

"ad...@jb..." wrote : "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 our 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.

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.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875774#3875774

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875774

[Jboss-dev-forums] [Design of AOP on JBoss (Aspects/JBoss)] - Re: aop in jboss webapp - request for help

[grafpoo <nu...@jb...>]

i am not using 'all', is that a requirement? what services above default does aop require?

and no, i did not set enableTransformations.

i'll repost the xml with code tags (it actually showed up in preview, dunno why it disappeared) if the above two don't sort it out. but am i correct in thinking that with annotations i can just use an empty jboss-aop.xml and with no mbeans an empty jboss-service.xml?

and thanks for the prompt and useful reply!

john


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875768#3875768

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875768

[Jboss-dev-forums] [Design of JBossXB] - Re: POJO Schema parsing

[<ale...@jb...>]

"ad...@jb..." wrote : 2) Even though I've told it the schema with the schema binding (including the real local
  | location) this has no affect on the entity resolver:
  | 
  |   | 4625 WARN  [EntityResolver] Entity is not registered, publicId=null systemId=file:/home/ejort/jboss-head/workspace/kernel/src/resources/xml-test/org/jboss/test/kern
  |   | el/xml/test/pojo-deployer_1_0.xsd
  |   | 

This is logged by the

  | package org.jboss.util.xml;
  | public class JBossEntityResolver implements EntityResolver
  | {
  |    private static final Logger log = Logger.getLogger(EntityResolver.class);
  | 

From getLocalEntityName method. Since this schema is not registered there yet.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875760#3875760

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875760

[Jboss-dev-forums] [TODO -- DEVELOPMENT] - Want to help in the area of container plugin

[rawat_tejinder <nu...@jb...>]

I saw the various message regarding null pointer excptions even after the ejb verifications and getting class loaders for beans.
  the problems are specially with persistence manager.

can some one tell me how can i contribute.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875759#3875759

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875759

[Jboss-dev-forums] [Design of JBossXB] - Re: POJO Schema parsing

[<ale...@jb...>]

I just tried commenting out schema location in testGenericBeanFactory.xml

  | <!--
  | <deployment xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  |    xsi:schemaLocation="urn:jboss:xml-deployer xml-deployer_1_0.xsd"
  |    xmlns="urn:jboss:xml-deployer">
  | -->
  | <deployment xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  |    xmlns="urn:jboss:xml-deployer">
  | 

It worked fine.

Warnings like this

  |  WARN [AttributesHandler] Attribute is not bound: element owner {urn:jboss:xml-deployer}deployment, attribute {http://www.w3.org/2001/XMLSchema-instance}schemaLocation
  | 

can be ignored. In fact, there is a property that doesn't include schema instance attributes into Attributes object. Setting it will remove these warnings.

I don't understand why NULL is returned. Passing SchemaBinding with handlers should do the job.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875758#3875758

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875758

[Jboss-dev-forums] [Design of JBossXB] - Re: POJO Schema parsing

[<ale...@jb...>]

I would like to see what you are doing. Could you post/send me the code? What kind of warnings? 

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875753#3875753

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875753

[Jboss-dev-forums] [Design of AOP on JBoss (Aspects/JBoss)] - Re: aop in jboss webapp - request for help

[<kab...@jb...>]

Are you using the 'all' configuration of jboss?
Have you set EnableTransformations to true in the AspectManagerService?

To paste your xml surround it with code tags...

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875741#3875741

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875741

[Jboss-dev-forums] [Design of AOP on JBoss (Aspects/JBoss)] - aop in jboss webapp - request for help

[grafpoo <nu...@jb...>]

i want to add an aspect on creating and closing hibernate sessions.
i am using java 5 with a webapp running jboss-4.0.1sp1.

just for a feel-good, my first aspect is a log-everywhere one, but i
cannot get it to work, so i am asking for help. i have a feeling that 
jboss is not even picking up on the fact that i have an aspect, so
hopefully that is the lone hurdle. here's what i did.

1) created a class JbossSessionMonitor:


package foo.aop;

import org.apache.log4j.Logger;
import org.hibernate.Session;
import org.jboss.aop.Aspect;
import org.jboss.aop.Bind;
import org.jboss.aop.PointcutDef;
import org.jboss.aop.advice.Scope;
import org.jboss.aop.joinpoint.MethodInvocation;
import org.jboss.aop.pointcut.Pointcut;

/**
 * @author john guthrie
 */
@Aspect(scope = Scope.PER_VM)
public class JbossSessionMonitor {
	private static Logger logger = Logger.getLogger(JbossSessionMonitor.class);
	
	@PointcutDef ("execution( public * org.hibernate.Session -> close(..) )")
	public static Pointcut closeSessionPointcut;

	@PointcutDef ("execution( public * org.hibernate.SessionFactory -> openSession(..) )")
	public static Pointcut openSessionPointcut;

	@PointcutDef ("execution( public * org.hibernate.Session -> getSession(..) )")
	public static Pointcut getSessionPointcut;
	
	@Bind (pointcut="foo.aop.JbossSessionMonitor.closeSessionPointcut")
	public Object closeSessionAdvice(MethodInvocation mi) throws Throwable {
		String msg = "closing session: " + sessionInfo(mi.getTargetObject());
		logger.error(msg);
		System.out.println(msg);
		return mi.invokeNext();
	}

	@Bind (pointcut="foo.aop.JbossSessionMonitor.openSessionPointcut")
	public Object openSessionAdvice(MethodInvocation mi) throws Throwable {
		Object o = mi.invokeNext();
		String msg = "opening session: " + sessionInfo(o);
		logger.error(msg);
		System.out.println(msg);
		return o;
	}
	
	@Bind (pointcut="foo.aop.JbossSessionMonitor.getSessionPointcut")
	public Object getSessionAdvice(MethodInvocation mi) throws Throwable {
		String msg = "getting session: " + sessionInfo(mi.getTargetObject());
		logger.error(msg);
		System.out.println(msg);
		return mi.invokeNext();
	}
	
	private String sessionInfo(Object o) {
		if (o instanceof Session) {
			return ((Session) o).toString();
		} else {
			return "NOT-A-SESSION (" + o.getClass().getName() + ")";
		}
	}

}


from what i could tell from the 'injbossaop' example that comes with jboss-aop,
what i needed to do to get this working is/was:
 1) create a file foo.aop that has my class (jar-style), plus a jboss-aop.xml
    in META-INF in foo.aop that just has an empty aop root element (empty because 
    the aspect info is all in annotations
 2) my regular foo.war
 3) a foo.sar that contains #1 and #2 (foo.aop and foo.war) and a jboss-service.xml
    with an empty server root element (since i am deploying no mbeans)
    
with this setup, i got no logging.

so i changed the jboss-aop.xml to include what i wanted, so it looks like this:
<?xml version="1.0" encoding="UTF-8"?>

	

   
       
   

   
       
   

   
       
   


updated the jars and redeployed. still nothing.

i next changed the log-level in the jboss log4j.xml to debug level for org.jboss.aop
i got no logs, which is what has me thinking that i am not telling jboss the proper
place(s) for the aop configuration.



View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3875739#3875739

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3875739

[Jboss-dev-forums] [Design the new POJO MicroContainer] - Re: AOP/Metadata integration config

[<ad...@jb...>]

"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

[Jboss-dev-forums] [Design the new POJO MicroContainer] - Re: AOP/Metadata integration config

[<ad...@jb...>]

"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

[Jboss-dev-forums] [Design the new POJO MicroContainer] - Re: AOP/Metadata integration config

[<ad...@jb...>]

"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

[Jboss-dev-forums] [Design the new POJO MicroContainer] - Re: AOP/Metadata integration config

[<bil...@jb...>]

"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

[Jboss-dev-forums] [Design the new POJO MicroContainer] - Re: AOP/Metadata integration config

[<bil...@jb...>]

"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

[Jboss-dev-forums] [Design the new POJO MicroContainer] - Re: AOP/Metadata integration config

[<ad...@jb...>]

"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

[Jboss-dev-forums] [Design the new POJO MicroContainer] - Re: AOP/Metadata integration config

[<ad...@jb...>]

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

[Jboss-dev-forums] [Design the new POJO MicroContainer] - Re: AOP/Metadata integration config

[<bil...@jb...>]

"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

[Jboss-dev-forums] [Design the new POJO MicroContainer] - Re: AOP/Metadata integration config

[<ad...@jb...>]

"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

[Jboss-dev-forums] [Design the new POJO MicroContainer] - Re: AOP/Metadata integration config

[<bil...@jb...>]

"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