yes, I think this could be a war-less decision :)
DP/interfaces required for remoting. Get/set required for cache/cmp instrumentation on AOP. There are some grey areas as to when we require interfaces and plain POJO for server only stuff. As Scott pointed out the JNDI rewrite as a AOP/DP or AOP/POJO service is a requirement to test our stuff. Securing the JNDI access would be done very simply with the framework wether it is behind an interface or methods of pojo is completely irrelevant except that interface is required for DP/remote which is the case ANYWAY as we use the J2EE interface definition of JNDI. If an object is |(O | is the interface ( are the methods to the object O is the actual implementation or (O for a pojo then using |[](O is the DP approach where the [] interception is like the current EJB implementation and what Hiram was proposing to do in the very beginning ([]O is the current AOP approach for POJO's. There shouldn't be a war in these two approaches and the interface one should systematically use DP marcf > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Bill Burke > Sent: Monday, March 03, 2003 2:09 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] Proposal for jboss-wide interceptor framework > > > The AOP framework really right now is only for POJO > interception. I do have the beginnings of DynamicProxies > though. The AOP POJO framework can intercept static and > member methods, constructors, and fields. YOu can define > metadata on a class via xml, as well as interceptor stacks at > the Class level. You can add interceptors to a specific > instance at runtime. I have ported 2 interceptors so far to > the AOP framework. TX and Security. Security compiles but is > currently untested. > > For a minimum, I'd like everybody to at least use the > Invocation object I've created for the AOP framework. The > payloads in the server/src/org/jboss/invocation/Invocation > object have been abstracted into > its own object (SimpleMetaData). The Invocation object holds the > interceptor chain and is typeless as well. What I mean by > typeless is that the Invocation object can be used for any > type of invocation. Method, field, Constructor, JMS message, > whatever. > > I'd like to finish the beginnings of the DP framework and > apply them to EJB client-side interceptors but am having a > hard time getting more than an hour at a time to focus on > this big change. > > For JMX, you can already define AOP interceptors just like > you would for any Java class. This isn't a complete solution > for JMX though since JMX is instance based and not class > based. The AOP framework has a concept of pointcuts. I'd > like to add a MBean pointcut. What will happen is all MBean > classes will be instrumented by the AOP framework. The AOP > manager will deploy JMX pointcuts/interceptions by adding > interceptors per MBean. The AOP framework already supports > adding interceptors to a specific Object instance. Its just > a matter of hooking up the configuration mechanism. I'm not > sure if this is a good enough solution yet. > > As far as remoting goes for AOP, I want to first go the > DynamicProxy route. If a user wants to remote a POJO, a > DynamicProxy is created and remote invocations go through > this proxy. EJB currently has client interceptors grouped as > proxy-invoker binding. I think this is the kind of approach > we could use for AOP at first. > > For EJBs, I think it is just a matter of finishing the AOP DP > framework and using it for client interceptors. This will > force EJBs to use the AOP Invocation object and to access > interceptors the same way as AOP, which is a little different. > > JMX remoting is a problem though because the client can > dynamically create a connection to an MBean via JMX > connectors. The problem is, how do you get the client-side > interceptor chain back to the client when the client creates > a connection? We don't have this problem with JNDI or EJB > because the client must go to a specific port (JNDI) or > repository(EJB to JNDI) and we can provide the client DPs there. > > My problem right now with all this stuff is that I cannot > seem to focus on it for more than an hour without getting > interrupted to do something else. > > Bill > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Behalf Of > > Nathan Phelps > > Sent: Sunday, March 02, 2003 4:17 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] Proposal for jboss-wide > interceptor framework > > > > > > > > I agree. As I begin the development of JMS/JBoss 4.0, I'm, > frankly, > > confused as to which direction to go concerning the interceptor > > framework--which project is THE project? There is some great work > > being done right now by a variety of people on this problem, but I > > have no idea how it all fits together--if it fits together. > I wish we > > could settle this problem, agree on which direction we are > going, and > > then get the code base stabilized so those of us building services > > that will use THE framework can have the confidence that > we're working > > with the right one and that it works as advertised. > > > > Thanks, > > > > Nathan > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of > > Scott M Stark > > Sent: Sunday, March 02, 2003 1:37 PM > > To: [EMAIL PROTECTED] > > Subject: Re: [JBoss-dev] Proposal for jboss-wide > interceptor framework > > > > Woa, before we have a full fledged interceptor war show up in main > > what is the status of the various JMX, AOP, etc interceptors and > > associated frameworks? > > It seems like several people are running around writing this without > > demonstrating > > how it applies to the existing services. A simple example > is how do I > > expose the > > existing JNDI naming service via RMI/JRMP and RMI/HTTP with > that ability > > to introduce security and persistence? > > > > xxxxxxxxxxxxxxxxxxxxxxxx > > Scott Stark > > Chief Technology Officer > > JBoss Group, LLC > > xxxxxxxxxxxxxxxxxxxxxxxx > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > _______________________________________________ > > Jboss-development mailing list > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
