Re: [JBoss-dev] Unified interceptors?

[Jason Dillon]

Well it is still possible to separate the two w/o unified interceptors. 
 Not including the bits from org.jboss.cmp (this stuff is very 
independent) there are about 150+ classes which are not directly 
dependent on the bits from org.jboss.ejb (and related).

Some bits are forced to remain in jboss/ejb when they logically do not 
belong there because of the dependence on 
org.jboss.ejb.plugins.AbstractInterceptor.  Also I am not really sure 
that the webapp stuff really belongs in the ejb module, but there is 
too much interaction with the org.jboss.metadata classes to pull them 
apart with out changes to the core meta data framework.

What is left over is:

  org.jboss.cmp (I am guessing this is some of the new cmp framework)
  org.jboss.proxy (the core proxy compiler bits, could move to common)
  org.jboss.aspect (not sure what this is doing here)
  org.jboss.cache (not sure what this is doing here)
  org.jboss.ejb.plugins.cmp.jdbc.JDBCUtil (required by org.jboss.cmp, 
does not depend on org.jboss.ejb)
  org.jboss.invocation (the invocation framework)
  org.jboss.jms (jms provider abstraction layer & asf fluff)
  org.jboss.jmx (legacy adapters, connectors and whatever... should go 
away or move to jmx?)
  org.jboss.logging (default log4j logging service)
  org.jboss.metadata.XmlLoadable (the only class which was not EJB/J2EE 
specific)
  org.jboss.naming (naming proto handlers, default service & helpers)
  org.jboss.security (jboss security interfaces, minus interceptors 
which depend on org.jboss.ejb)
  org.jboss.Shutdown (depends on the jmx fluff and should move to 
system once jmx/remote stuff is cleaned up)

Does anyone know if any of the above is obsolete and can be removed?

I still believe that making the EJB-specific components of JBoss 
separate from the core system & services is a very, very good idea.  It 
will help keep JBoss a generic framework by forcing developers to keep 
service and system classes and components separate.  It will also help 
promote the fact that JBoss is not just an EJB container, or rather 
isn't an EJB container at all... just a generic framework which happens 
to also provide EJB/J2EE services.

I feel that for the most part, the rest of the server is quite well 
organized into logical chunks of functionality.  It is just this module 
which is the "kitchen sink" which has been bothering me for quite some 
time.  I do not believe it is just a style issue either.  Separation of 
functionality makes for better software engineering by isolation of 
similar components, which promotes simpler builds as well as unit and 
integration testing.

So, I think we should make the change, but I think it will be best to 
wait until the unified interceptor work has been completed.  Hopefully 
that will be done by middle of next week, after which I can redo this 
separation, now that I have discovered all of the interaction points.  
Once that has been completed and proves functional via the testsuite I 
think we should move the cmp2 bits to its own home.

Comments?

--jason



-------------------------------------------------------
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