Re: [JBoss-dev] Remote class loading servlet
Hi,
just curious: will this work with a scoped ear-deployer. How are EJBS:
deployed from within a scoped ear-deployer made available to the servlet
classloader? With WebService this was done through addClassLoader(), but
how is it done in this servlet aproach?
//Peter
On Mon, 2003-02-17 at 19:33, James Cooley wrote:
Hi Dain,
I wrote a servlet (attached) and it looks like it will simplify
things.
It effectively replaces WebService and WebServer (WebService
simply wraps WebServer). WebClassLoader doesn't have a dependency on
WebServ* so it can operate as normal. I ran the DynLoadingUnitTestCase
and it passes. Funnily enough it passes if it succeeds with
./build.sh -Dtest=jrmp tests-client-unit
but fails with
./build.sh -Dtest=jrmp test
I think this is how it's supposed to be called at any rate.
A couple of points:
1. I didn't implement addClassLoader - AFAIK Scott said we will use the
servlets class loader to retrieve all classes. Removing addClassLoader
doesn't appear to cause a problem.
2. The WebServ* classes should be removed.
3. run.sh/run.bat will have to be updated with
-Djava.rmi.server.codebase=http://localhost:8080/class-loader/
4. Do we need to have a jmx service for this?
I've been working on the 3.2 branch but it should work with 4.0. I have
been using my own xdoclet ant script to build it as a .war - do you want
me to use another deployment script as a template?
I'll have some time over the next couple of days to write a compliant
build script and make any other changes you may want.
James
Dain Sundstrom wrote:
We have a small project open for a volunteer. In Jboss 2 and 3 we have
a custom lightweight web server (port 8083) that returns java class
files from the classLoader.getResouceAsStream to RMI clients (this is
how remote class loading happens). I talked to Scott at JBoss Boot Camp
and we think it is a good idea to replace this with a plain old Servlet
for JBoss 4.0 so it can work with regular security, pooling and such.
This is a fairly simple piece of code and shouldn't take longer then a
day or two. If you are interested the code can be found in
jboss-head/server/src/main/org/jboss/web/WebServer.java
-dain
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
/* JBoss, the OpenSource J2EE webOS
*
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
package org.jboss.web;
import javax.servlet.ServletException;
import javax.servlet.ServletConfig;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;
import java.io.InputStream;
import org.jboss.logging.Logger;
import org.jboss.util.stream.Streams;
/**
* The HTTPClassLoader Servlet's primary purpose is to simplify dynamic
class-loading in RMI.
*
* It can serve any file that is available, including class-files.
* This is a replacement for the WebServer class in this package.
*
* @web.servlet
* display-name=JBoss HTTPClassLoaderServlet
* load-on-startup=1
* name=HTTPClassLoaderServlet
*
* @web.servlet-mapping
* url-pattern=/*
*
* @link org.jboss.test.jrmp.test.DynLoadingUnitTestCase
* @see http://java.sun.com/j2se/1.4/docs/guide/rmi/codebase.html
*
* @author a href=mailto:[EMAIL PROTECTED];James Cooley/a
*/
public class HTTPClassLoaderServlet extends HttpServlet
{
// Constants -
// Attributes
private static Logger log = Logger.getLogger(HTTPClassLoaderServlet.class);
public static final String CONTENT_TYPE = application/binary;
public void init(ServletConfig conf) throws ServletException
{
super.init(conf);
}
/**
* Called by the server (via the service method) to allow a servlet to handle a
POST request.
* The HTTP POST method allows the client to send data of unlimited length to the
Web server
* a single time and is useful when posting information such as credit card
numbers.
*/
public void doPost(HttpServletRequest request, HttpServletResponse response)
throws IOException, ServletException
{
log.trace(post called);
doGet(request, response);
}
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException
{
String filePath = null;
boolean traceOn = log.isTraceEnabled();
Re: [JBoss-dev] Remote class loading servlet
On Fri, 2003-02-21 at 16:52, James Cooley wrote:
Hi Peter,
This was not a requirement for the servlet and I haven't included it -
see previous mails. Scott is deciding how we will integrate the servlet
into the JBoss startup script and retire the WebService. He might best
explain how this will be addressed.
Ok. If there are no new ways of adding the classloader of EJB:s deployed
through an ear with a scoped repository this means that dynamic rmi
classloading will not work for these EJB:s as far as I can see it.
//Peter
Rgds,
James
Peter Antman wrote:
Hi,
just curious: will this work with a scoped ear-deployer. How are EJBS:
deployed from within a scoped ear-deployer made available to the servlet
classloader? With WebService this was done through addClassLoader(), but
how is it done in this servlet aproach?
//Peter
On Mon, 2003-02-17 at 19:33, James Cooley wrote:
Hi Dain,
I wrote a servlet (attached) and it looks like it will simplify
things.
It effectively replaces WebService and WebServer (WebService
simply wraps WebServer). WebClassLoader doesn't have a dependency on
WebServ* so it can operate as normal. I ran the DynLoadingUnitTestCase
and it passes. Funnily enough it passes if it succeeds with
./build.sh -Dtest=jrmp tests-client-unit
but fails with
./build.sh -Dtest=jrmp test
I think this is how it's supposed to be called at any rate.
A couple of points:
1. I didn't implement addClassLoader - AFAIK Scott said we will use the
servlets class loader to retrieve all classes. Removing addClassLoader
doesn't appear to cause a problem.
2. The WebServ* classes should be removed.
3. run.sh/run.bat will have to be updated with
-Djava.rmi.server.codebase=http://localhost:8080/class-loader/
4. Do we need to have a jmx service for this?
I've been working on the 3.2 branch but it should work with 4.0. I have
been using my own xdoclet ant script to build it as a .war - do you want
me to use another deployment script as a template?
I'll have some time over the next couple of days to write a compliant
build script and make any other changes you may want.
James
Dain Sundstrom wrote:
We have a small project open for a volunteer. In Jboss 2 and 3 we have
a custom lightweight web server (port 8083) that returns java class
files from the classLoader.getResouceAsStream to RMI clients (this is
how remote class loading happens). I talked to Scott at JBoss Boot Camp
and we think it is a good idea to replace this with a plain old Servlet
for JBoss 4.0 so it can work with regular security, pooling and such.
This is a fairly simple piece of code and shouldn't take longer then a
day or two. If you are interested the code can be found in
jboss-head/server/src/main/org/jboss/web/WebServer.java
-dain
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
/* JBoss, the OpenSource J2EE webOS
*
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
package org.jboss.web;
import javax.servlet.ServletException;
import javax.servlet.ServletConfig;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;
import java.io.InputStream;
import org.jboss.logging.Logger;
import org.jboss.util.stream.Streams;
/**
* The HTTPClassLoader Servlet's primary purpose is to simplify dynamic
class-loading in RMI.
*
* It can serve any file that is available, including class-files.
* This is a replacement for the WebServer class in this package.
*
* @web.servlet
* display-name=JBoss HTTPClassLoaderServlet
* load-on-startup=1
* name=HTTPClassLoaderServlet
*
* @web.servlet-mapping
* url-pattern=/*
*
* @link org.jboss.test.jrmp.test.DynLoadingUnitTestCase
* @see http://java.sun.com/j2se/1.4/docs/guide/rmi/codebase.html
*
* @author a href=mailto:[EMAIL PROTECTED];James Cooley/a
*/
public class HTTPClassLoaderServlet extends HttpServlet
{
// Constants -
// Attributes
private static Logger log = Logger.getLogger(HTTPClassLoaderServlet.class);
public static final String CONTENT_TYPE = application/binary;
public void init(ServletConfig conf) throws ServletException
{
super.init(conf);
}
/**
* Called by the server (via the service method) to allow a servlet to handle a
POST request.
* The HTTP POST method allows the client to send
[JBoss-dev] Jboss-mx errors
I'm getting a bunch of these errors while building fresh checkout of jboss-mx from HEAD. Anyone have any ideas? [execmodules] C:\cvs-jboss-head\jboss-mx\jmx\src\main\org\jboss\mx\metadata\JBossXMBean10.java:37: package org.dom4j does not exist[execmodules] import org.dom4j.Document;[execmodules] ^[execmodules] C:\cvs-jboss-head\jboss-mx\jmx\src\main\org\jboss\mx\metadata\JBossXMBean10.java:38: package org.dom4j does not exist[execmodules] import org.dom4j.DocumentException;[execmodules] ^[execmodules] C:\cvs-jboss-head\jboss-mx\jmx\src\main\org\jboss\mx\metadata\JBossXMBean10.java:39: package org.dom4j does not exist[execmodules] import org.dom4j.Element;[execmodules] ^[execmodules] C:\cvs-jboss-head\jboss-mx\jmx\src\main\org\jboss\mx\metadata\JBossXMBean10.java:40: package org.dom4j.iodoes not exist[execmodules] import org.dom4j.io.SAXReader;[execmodules] ^[execmodules] C:\cvs-jboss-head\jboss-mx\jmx\src\main\org\jboss\mx\metadata\JBossXMBean10.java:63: cannot resolve symbol [execmodules] symbol : class Element[execmodules] location: class org.jboss.mx.metadata.JBossXMBean10[execmodules] private Element element;[execmodules] ^[execmodules] C:\cvs-jboss-head\jboss-mx\jmx\src\main\org\jboss\mx\metadata\JBossXMBean10.java:78: cannot resolve symbol [execmodules] symbol : class Element[execmodules] location: class org.jboss.mx.metadata.JBossXMBean10[execmodules] public JBossXMBean10(String mmbClassName, String resourceClassName, Element element, Map properties)[execmodules] ^[execmodules] C:\cvs-jboss-head\jboss-mx\jmx\src\main\org\jboss\mx\metadata\JBossXMBean10.java:127: cannot resolve symbol[execmodules] symbol : class Element[execmodules] location: class org.jboss.mx.metadata.JBossXMBean10[execmodules] protected Descriptor getDescriptor(final Element parent, final String infoName, final String type) throws NotCompliantMBeanException[execmodules] ^[execmodules] C:\cvs-jboss-head\jboss-mx\jmx\src\main\org\jboss\mx\metadata\JBossXMBean12.java:9: package org.dom4j doesnot exist[execmodules] import org.dom4j.Attribute;[execmodules] ^[execmodules] C:\cvs-jboss-head\jboss-mx\jmx\src\main\org\jboss\mx\metadata\JBossXMBean12.java:10: package org.dom4j doe
RE: [JBoss-dev] Jboss-mx errors
jmx/build.xml probably needs to reference dom4j.jar. I just check out last night at 10 pm with no problems. Did you do an update instead of a clean checkout? I don't think update grabs thirdparty jars for some reason. -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Jeff HaynieSent: Friday, February 21, 2003 12:43 PMTo: [EMAIL PROTECTED]Subject: [JBoss-dev] Jboss-mx errors I'm getting a bunch of these errors while building fresh checkout of jboss-mx from HEAD. Anyone have any ideas? [execmodules] C:\cvs-jboss-head\jboss-mx\jmx\src\main\org\jboss\mx\metadata\JBossXMBean10.java:37: package org.dom4j does not exist[execmodules] import org.dom4j.Document;[execmodules] ^[execmodules] C:\cvs-jboss-head\jboss-mx\jmx\src\main\org\jboss\mx\metadata\JBossXMBean10.java:38: package org.dom4j does not exist[execmodules] import org.dom4j.DocumentException;[execmodules] ^[execmodules] C:\cvs-jboss-head\jboss-mx\jmx\src\main\org\jboss\mx\metadata\JBossXMBean10.java:39: package org.dom4j does not exist[execmodules] import org.dom4j.Element;[execmodules] ^[execmodules] C:\cvs-jboss-head\jboss-mx\jmx\src\main\org\jboss\mx\metadata\JBossXMBean10.java:40: package org.dom4j.iodoes not exist[execmodules] import org.dom4j.io.SAXReader;[execmodules] ^[execmodules] C:\cvs-jboss-head\jboss-mx\jmx\src\main\org\jboss\mx\metadata\JBossXMBean10.java:63: cannot resolve symbol [execmodules] symbol : class Element[execmodules] location: class org.jboss.mx.metadata.JBossXMBean10[execmodules] private Element element;[execmodules] ^[execmodules] C:\cvs-jboss-head\jboss-mx\jmx\src\main\org\jboss\mx\metadata\JBossXMBean10.java:78: cannot resolve symbol [execmodules] symbol : class Element[execmodules] location: class org.jboss.mx.metadata.JBossXMBean10[execmodules] public JBossXMBean10(String mmbClassName, String resourceClassName, Element element, Map properties)[execmodules] ^[execmodules] C:\cvs-jboss-head\jboss-mx\jmx\src\main\org\jboss\mx\metadata\JBossXMBean10.java:127: cannot resolve symbol[execmodules] symbol : class Element[execmodules] location: class org.jboss.mx.metadata.JBossXMBean10[execmodules] protected Descriptor getDescriptor(final Element parent, final String infoName, final String type) throws NotCompliantMBeanException[execmodules] ^[execmodules] C:\cvs-jboss-head\jboss-mx\jmx\src\main\org\jboss\mx\metadata\JBossXMBean12.java:9: package org.dom4j doesnot exist[execmodules] import org.dom4j.Attribute;[execmodules] ^[execmodules] C:\cvs-jboss-head\jboss-mx\jmx\src\main\org\jboss\mx\metadata\JBossXMBean12.java:10: package org.dom4j doe
RE: [JBoss-dev] Jboss-mx errors
Title: Message OK, this is fixed. -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff HaynieSent: Friday, February 21, 2003 12:54 PMTo: [EMAIL PROTECTED]Subject: RE: [JBoss-dev] Jboss-mx errors i did a brand new checkout into a clean directory. i'll fix the build. thanks, -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill BurkeSent: Friday, February 21, 2003 12:49 PMTo: [EMAIL PROTECTED]Subject: RE: [JBoss-dev] Jboss-mx errors jmx/build.xml probably needs to reference dom4j.jar. I just check out last night at 10 pm with no problems. Did you do an update instead of a clean checkout? I don't think update grabs thirdparty jars for some reason. -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Jeff HaynieSent: Friday, February 21, 2003 12:43 PMTo: [EMAIL PROTECTED]Subject: [JBoss-dev] Jboss-mx errors I'm getting a bunch of these errors while building fresh checkout of jboss-mx from HEAD. Anyone have any ideas? [execmodules] C:\cvs-jboss-head\jboss-mx\jmx\src\main\org\jboss\mx\metadata\JBossXMBean10.java:37: package org.dom4j does not exist[execmodules] import org.dom4j.Document;[execmodules] ^[execmodules] C:\cvs-jboss-head\jboss-mx\jmx\src\main\org\jboss\mx\metadata\JBossXMBean10.java:38: package org.dom4j does not exist[execmodules] import org.dom4j.DocumentException;[execmodules] ^[execmodules] C:\cvs-jboss-head\jboss-mx\jmx\src\main\org\jboss\mx\metadata\JBossXMBean10.java:39: package org.dom4j does not exist[execmodules] import org.dom4j.Element;[execmodules] ^[execmodules] C:\cvs-jboss-head\jboss-mx\jmx\src\main\org\jboss\mx\metadata\JBossXMBean10.java:40: package org.dom4j.iodoes not exist[execmodules] import org.dom4j.io.SAXReader;[execmodules] ^[execmodules] C:\cvs-jboss-head\jboss-mx\jmx\src\main\org\jboss\mx\metadata\JBossXMBean10.java:63: cannot resolve symbol [execmodules] symbol : class Element[execmodules] location: class org.jboss.mx.metadata.JBossXMBean10[execmodules] private Element element;[execmodules] ^[execmodules] C:\cvs-jboss-head\jboss-mx\jmx\src\main\org\jboss\mx\metadata\JBossXMBean10.java:78: cannot resolve symbol [execmodules] symbol : class Element[execmodules] location: class org.jboss.mx.metadata.JBossXMBean10[execmodules] public JBossXMBean10(String mmbClassName, String resourceClassName, Element element, Map properties)[execmodules] ^[execmodules] C:\cvs-jboss-head\jboss-mx\jmx\src\main\org\jboss\mx\metadata\JBossXMBean10.java:127: cannot resolve symbol[execmodules] symbol : class Element[execmodules] location: class org.jboss.mx.metadata.JBossXMBean10[execmodules] protected Descriptor getDescriptor(final Element parent, final String infoName, final String type) throws NotCompliantMBeanException[execmodules] ^[execmodules] C:\cvs-jboss-head\jboss-mx\jmx\src\main\org\jboss\mx\metadata\JBossXMBean12.java:9: package org.dom4j doesnot exist[execmodules] import org.dom4j.Attribute;[execmodules] ^[execmodules] C:\cvs-jboss-head\jboss-mx\jmx\src\main\org\jboss\mx\metadata\JBossXMBean12.java:10: package org.dom4j doe
[JBoss-dev] [ jboss-Bugs-690177 ] JBoss startup does not work under linux
Bugs item #690177, was opened at 2003-02-20 18:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=690177group_id=22866 Category: JBoss-IDE Group: None Status: Closed Resolution: Fixed Priority: 9 Submitted By: Hans Dockter (hans_d) Assigned to: Hans Dockter (hans_d) Summary: JBoss startup does not work under linux Initial Comment: JBoss 3.2 from cThis bug was mentioned in the froum by Bernd Koeke and others: Eclipse 2.1 M5 Both on Sun JDK 1.4.1_01 SuSE Linux 8.0 I have one JBoss outside the workspace, which I build by hand with build.sh and I use tomcat41 (tomcat 4.1.18 LE jdk1.4). Another JBoss 3.2 is checked out in eclipse for debugging. When I start JBoss by run.sh with a run.conf for remote debugging, e.g. on port 8000 and configure JBoss remote it works. But when I want to start it with a JBoss 3.x configuration I get the following message in a popup: org.eclipse.core.runtime.CoreException Could not connect to VM and in the console window: Exception in thread main java.lang.NoClassDefFoundError: -- Comment By: Hans Dockter (hans_d) Date: 2003-02-21 20:06 Message: Logged In: YES user_id=588418 Under linux it has lead to an error that an additional space was at the end of the vmArgs. This is fixed now. -- Comment By: John Schult (jdschult) Date: 2003-02-20 21:59 Message: Logged In: YES user_id=491610 An additional configuration that produces same behavior is: RH Linux 8.0 Sun JDK 1.3.1 JBoss 2.4.4 Eclipse M5 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=690177group_id=22866 --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 21-February-2003
JBoss daily test results SUMMARY Number of tests run: 1043 Successful tests: 1038 Errors:2 Failures: 3 [time of test: 2003-02-21.12-05 GMT] [java.version: 1.3.1] [java.vendor: Apple Computer, Inc.] [java.vm.version: 1.3.1_03-69] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Mac OS X] [os.arch: ppc] [os.version: 10.2.4] See http://users.jboss.org/~starksm/Branch_3_0/2003-02-21.12-05 for details of this test. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS Suite: MissingClassUnitTestCase Test: testDeployServiceWithoutClass(org.jboss.test.jmx.test.MissingClassUnitTestCase) Type:error Exception: org.jboss.deployment.DeploymentException Message: jboss.test:name=missingclasstest is not registered.; - nested throwable: (javax.management.InstanceNotFoundException: jboss.test:name=missingclasstest is not registered.) - Suite: SecurityUnitTestCase Test:testSecureHttpInvoker(org.jboss.test.naming.test.SecurityUnitTestCase) Type:failure Exception: junit.framework.AssertionFailedError Message: Should not have been able to lookup(invokers) - Suite: SecurityUnitTestCase Test: testSecureHttpInvokerFailure(org.jboss.test.naming.test.SecurityUnitTestCase) Type:failure Exception: junit.framework.AssertionFailedError Message: Should not have been able to lookup(invokers) - Suite: BeanStressTestCase Test:testDeadLockFromClient(org.jboss.test.deadlock.test.BeanStressTestCase) Type:failure Exception: junit.framework.AssertionFailedError Message: expected a client deadlock for AB BA - Suite: HelloClusteredHttpStressTestCase Test:testCNFEObject(org.jboss.test.hello.test.HelloClusteredHttpStressTestCase) Type:error Exception: java.rmi.ServerException Message: Service unavailable last exception: - --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] TxInterceptor split is really really bad
I've been thinking and should have posted this before. Your design is fataly flawed when I start applying it to the AOP framework. Your design assumes that there is a proxy sitting in front of everything. In AOP this is not the case. If you look at varia/src/org/jboss/aop/plugins/TxSupport.java you'll see that I had to combine the clientInvoke and serverInvoke into one method because there is no proxy object between the application code and the object instance. Ok...no problem you sayWell, think of what happens when the app developer decides to remote an AOP'd object. I will have to have 2 sets of interceptor chains and have to figure out whether the call is a remote call or local. Well, I guess I could insert a flag into the Invocation on whether the call went through a proxy or not. But do you see where I'm going? I don't think its a good design to rely on the client to handle transaction semantics. I don't think its a good idea for the server to have to rely on client logic unless it really has to. All and all, my gut tells me that the current client/tx design will cause problems. I want interceptor designers in general to avoid this kind of dependency. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David Jencks Sent: Wednesday, February 19, 2003 11:02 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really good On 2003.02.19 09:37 Bill Burke wrote: What you implemented is fine. My only problem with it is that I think it is more logical to let the server decide if it needs the tx, and that I think the registration callback could be avoided (with minimal redundant client side bookkeeping) even if the decision is made on the server side. I got the impression that this implementation would also be used in the other invokers, and that made me worry about CORBA interoperability. If this approach will not be used with the IIOP invoker, I have no problem with it. Yes this was my exact worry and still is. That we'll have to have a different set of interceptors on the server side for different transports. This is unexceptable because we want each EJB to be able to listen to and service calls from different transports at the same time. David, I'm not suggesting to redesign your code, but is the design flexible enough so that we could switch to a server-side based design? Iteration is a fine thing I don't think we will have problems adapting my current design to use corba. Before we continue I think we should get a clear understanding of what is supposed to happen when the corba tx policy and the j2ee tx support disagree. Does anyone know where this is described in specs? Basically the corba design says if there is a transaction in the context it must always be transmitted and imported on the server whereas j2ee does not always need to import the tx. The purpose of the client side interceptor is to not generate tx branches that won't be used. I think that any reasonable corba implementation is going to follow corba semantics and always generate a transaction branch on the client for the remote call, since as far as the corba spec goes, if the call is made within a tx the transaction will in fact be used on the server. In my view the heaviest part of the process is generating a tx branch on the client: once it is generated, then it has to be prepared and/or committed. The communication overhead on these messages is likely to dwarf any other resource usage. The choices I can see here are: 1. only generate the branch if it is needed, but do it right away. This is what I implemented and I think it is simplest and the only one that is likely to be comprehensible when someone looks at it in a week or two. 2. Only generate the branch if it is needed but do it after the work is done. I think this is Ole's proposal. This introduces a lot of bookkeeping on the client to associate client side transactions to branches. I don't think I'd be able to maintain this code, in a week I wouldn't remember how it worked. After spending a day to figure it out, I'd simplify it to (1). 3. Always generate a branch immediately, but have the xaresource return read-only on prepare if the tx did not need to be imported. This is unacceptable because it forces 2pc in the case that there is only one other branch. Don't we need a client side method-to-method-attributes map anyway for many other purposes such as determining if a return value can be cached? david Bill --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___
RE: [JBoss-dev] TxInterceptor split is really really bad
I'm getting kind of tired of what I find vague complaints without detailed explanations of the framework in which you think there might be a problem. I think remote AOP is going to need; 1. some representation of the object you are calling 2. client interceptors. For instance, to get the security context. 3. a transport mechanism 4. something on the other end of the transport mechanism to find the right target 5. server side interceptors If you disagree please explain in detail what you propose. Personally I think the AOP stuff should do this always, with a possible null transport mechanism, at least for remotable objects. If you agree, then I hope you will agree that there has to be some metadata on the client side to define the client interceptors and the transport. If there is some place to put metadata, why can't I use it for the tx support? I would like to note that my future plans for this involve method specific interceptor chains with a variety of client side and server side tx interceptors, each one performing half of the TxSupport work. No maps, just different specialized interceptors, with different interceptors per method depending on the tx support. I also think you will admit that even in aop you could have two interceptors even if both were on the server side: one to get the tx from the context if appropriate or remove it if appropriate, one to start a new tx if appropriate. On 2003.02.21 16:12 Bill Burke wrote: I've been thinking and should have posted this before. Your design is fataly flawed when I start applying it to the AOP framework. Your design assumes that there is a proxy sitting in front of everything. In AOP this is not the case. If you look at varia/src/org/jboss/aop/plugins/TxSupport.java you'll see that I had to combine the clientInvoke and serverInvoke into one method because there is no proxy object between the application code and the object instance. You could have written two separate interceptors, one with the client invoke and one with the server invoke. Ok...no problem you sayWell, think of what happens when the app developer decides to remote an AOP'd object. I will have to have 2 sets of interceptor chains and have to figure out whether the call is a remote call or local. Well, I guess I could insert a flag into the Invocation on whether the call went through a proxy or not. Do you mean transport? I don't understand. But do you see where I'm going? nope I don't think its a good design to rely on the client to handle transaction semantics. I don't think its a good idea for the server to have to rely on client logic unless it really has to. So serialization and RMI are a bad idea because they allow moving server logic to the client? In this case the transaction support HAS TO RELY ON THE CLIENT TRANSACTION MANAGER or there will be no dtm. I don't understand why you are getting your knickers in such a twist when I want to move some static data to the client to reduce complexity and comply with the industry standard dtm spec. david All and all, my gut tells me that the current client/tx design will cause problems. I want interceptor designers in general to avoid this kind of dependency. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David Jencks Sent: Wednesday, February 19, 2003 11:02 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really good On 2003.02.19 09:37 Bill Burke wrote: What you implemented is fine. My only problem with it is that I think it is more logical to let the server decide if it needs the tx, and that I think the registration callback could be avoided (with minimal redundant client side bookkeeping) even if the decision is made on the server side. I got the impression that this implementation would also be used in the other invokers, and that made me worry about CORBA interoperability. If this approach will not be used with the IIOP invoker, I have no problem with it. Yes this was my exact worry and still is. That we'll have to have a different set of interceptors on the server side for different transports. This is unexceptable because we want each EJB to be able to listen to and service calls from different transports at the same time. David, I'm not suggesting to redesign your code, but is the design flexible enough so that we could switch to a server-side based design? Iteration is a fine thing I don't think we will have problems adapting my current design to use corba. Before we continue I think we should get a clear understanding of what is supposed to happen when the corba tx policy and the j2ee tx support disagree. Does anyone know where this is described in specs? Basically the corba design says if there is a transaction in the context it must always
RE: [JBoss-dev] TxInterceptor split is really really bad
I have to disagree. Take a higher level look at the basics: All client proxies have a dependency on their corresponsing server side stub. You can't mix a different proxys and stub types. Therefore it is ok for a client side interceptor to have a dependency on the server side interceptor. Can you describe your AOP problem in more detail. How are you going to be remoting POJO with AOP?? With a proxy? Who will create the proxy objet? Regards, Hiram --- Bill Burke [EMAIL PROTECTED] wrote: Ok, maybe I shouldn't have said fatally flawed. But again, my gut tells me that it is bad to have a dependency between server and client interceptors if it is not absolutely needed. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Bill Burke Sent: Friday, February 21, 2003 4:12 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad I've been thinking and should have posted this before. Your design is fataly flawed when I start applying it to the AOP framework. Your design assumes that there is a proxy sitting in front of everything. In AOP this is not the case. If you look at varia/src/org/jboss/aop/plugins/TxSupport.java you'll see that I had to combine the clientInvoke and serverInvoke into one method because there is no proxy object between the application code and the object instance. Ok...no problem you sayWell, think of what happens when the app developer decides to remote an AOP'd object. I will have to have 2 sets of interceptor chains and have to figure out whether the call is a remote call or local. Well, I guess I could insert a flag into the Invocation on whether the call went through a proxy or not. But do you see where I'm going? I don't think its a good design to rely on the client to handle transaction semantics. I don't think its a good idea for the server to have to rely on client logic unless it really has to. All and all, my gut tells me that the current client/tx design will cause problems. I want interceptor designers in general to avoid this kind of dependency. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David Jencks Sent: Wednesday, February 19, 2003 11:02 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really good On 2003.02.19 09:37 Bill Burke wrote: What you implemented is fine. My only problem with it is that I think it is more logical to let the server decide if it needs the tx, and that I think the registration callback could be avoided (with minimal redundant client side bookkeeping) even if the decision is made on the server side. I got the impression that this implementation would also be used in the other invokers, and that made me worry about CORBA interoperability. If this approach will not be used with the IIOP invoker, I have no problem with it. Yes this was my exact worry and still is. That we'll have to have a different set of interceptors on the server side for different transports. This is unexceptable because we want each EJB to be able to listen to and service calls from different transports at the same time. David, I'm not suggesting to redesign your code, but is the design flexible enough so that we could switch to a server-side based design? Iteration is a fine thing I don't think we will have problems adapting my current design to use corba. Before we continue I think we should get a clear understanding of what is supposed to happen when the corba tx policy and the j2ee tx support disagree. Does anyone know where this is described in specs? Basically the corba design says if there is a transaction in the context it must always be transmitted and imported on the server whereas j2ee does not always need to import the tx. The purpose of the client side interceptor is to not generate tx branches that won't be used. I think that any reasonable corba implementation is going to follow corba semantics and always generate a transaction branch on the client for the remote call, since as far as the corba spec goes, if the call is made within a tx the transaction will in fact be used on the server. In my view the heaviest part of the process is generating a tx branch on the client: once it is generated, then it has to be prepared and/or committed. The communication overhead on these messages is likely to dwarf any other resource usage. The choices I can see here are: 1. only generate the branch if it is needed, but do it right away. This is what I implemented and I think it is simplest and the only one that is likely to be comprehensible
RE: [JBoss-dev] TxInterceptor split is really really bad
I think AOP has a separate functional requirement from Remoting and should be separated. Remoting depends (potentially) on AOP. AOP should be the instrumenting, invocation and interception framework. Remoting should then add any semantics for transport and discovery. Individual subsystems (JMX,JMS,EJB), then have a client side proxy (of some sorts, yet to be determined) and a server side invocation handler that know how to convert the local invocation into a remote one using the remoting framework (CLIENT) and know how to take the remote invocation and create a local invocation and return it (SERVER). We should de-couple them into their respective modules of responsibility and functionality. I think the remote tx stuff should be an AOP interceptor that is applied to the EJB client side side remote proxy (that makes the client invoker via remoting) by adding the TX to the invocation payload and then on the other side extracting the TX from the invocation and applying... I personally don't think AOP should have anything related to transactions, remoting, etc. I think that should be pushed up into the functional areas that apply those specific semantics to the subsystems since they are quite different depending on the subsystem (JMS, EJB, etc) and location (local,remote). -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Friday, February 21, 2003 5:17 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad I have to disagree. Take a higher level look at the basics: All client proxies have a dependency on their corresponsing server side stub. You can't mix a different proxys and stub types. Therefore it is ok for a client side interceptor to have a dependency on the server side interceptor. Can you describe your AOP problem in more detail. How are you going to be remoting POJO with AOP?? With a proxy? Who will create the proxy objet? Regards, Hiram --- Bill Burke [EMAIL PROTECTED] wrote: Ok, maybe I shouldn't have said fatally flawed. But again, my gut tells me that it is bad to have a dependency between server and client interceptors if it is not absolutely needed. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Bill Burke Sent: Friday, February 21, 2003 4:12 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad I've been thinking and should have posted this before. Your design is fataly flawed when I start applying it to the AOP framework. Your design assumes that there is a proxy sitting in front of everything. In AOP this is not the case. If you look at varia/src/org/jboss/aop/plugins/TxSupport.java you'll see that I had to combine the clientInvoke and serverInvoke into one method because there is no proxy object between the application code and the object instance. Ok...no problem you sayWell, think of what happens when the app developer decides to remote an AOP'd object. I will have to have 2 sets of interceptor chains and have to figure out whether the call is a remote call or local. Well, I guess I could insert a flag into the Invocation on whether the call went through a proxy or not. But do you see where I'm going? I don't think its a good design to rely on the client to handle transaction semantics. I don't think its a good idea for the server to have to rely on client logic unless it really has to. All and all, my gut tells me that the current client/tx design will cause problems. I want interceptor designers in general to avoid this kind of dependency. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David Jencks Sent: Wednesday, February 19, 2003 11:02 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really good On 2003.02.19 09:37 Bill Burke wrote: What you implemented is fine. My only problem with it is that I think it is more logical to let the server decide if it needs the tx, and that I think the registration callback could be avoided (with minimal redundant client side bookkeeping) even if the decision is made on the server side. I got the impression that this implementation would also be used in the other invokers, and that made me worry about CORBA interoperability. If this approach will not be used with the IIOP invoker, I have no problem with it. Yes this was my exact worry and still is. That we'll have to have a different set of interceptors on the server side for different transports. This is unexceptable because we want each EJB to be able to listen to and service calls from different transports at the same time. David, I'm not suggesting to redesign your code, but is the
RE: [JBoss-dev] TxInterceptor split is really really bad
I personally don't think AOP should have anything related to transactions, remoting, etc. I think that should be pushed up into the functional areas that apply those specific semantics to the subsystems since they are quite different depending on the subsystem (JMS, EJB, etc) and location (local,remote). Where have you been? Marc has been talking about creating an AOP framework and services on top of this framework since the fall. The whole point is to break ourselves away from EJB and isolate and abstract out distribution infrastructure even more from a coding perspective. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Friday, February 21, 2003 5:17 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad I have to disagree. Take a higher level look at the basics: All client proxies have a dependency on their corresponsing server side stub. You can't mix a different proxys and stub types. Therefore it is ok for a client side interceptor to have a dependency on the server side interceptor. Can you describe your AOP problem in more detail. How are you going to be remoting POJO with AOP?? With a proxy? Who will create the proxy objet? Regards, Hiram --- Bill Burke [EMAIL PROTECTED] wrote: Ok, maybe I shouldn't have said fatally flawed. But again, my gut tells me that it is bad to have a dependency between server and client interceptors if it is not absolutely needed. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Bill Burke Sent: Friday, February 21, 2003 4:12 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad I've been thinking and should have posted this before. Your design is fataly flawed when I start applying it to the AOP framework. Your design assumes that there is a proxy sitting in front of everything. In AOP this is not the case. If you look at varia/src/org/jboss/aop/plugins/TxSupport.java you'll see that I had to combine the clientInvoke and serverInvoke into one method because there is no proxy object between the application code and the object instance. Ok...no problem you sayWell, think of what happens when the app developer decides to remote an AOP'd object. I will have to have 2 sets of interceptor chains and have to figure out whether the call is a remote call or local. Well, I guess I could insert a flag into the Invocation on whether the call went through a proxy or not. But do you see where I'm going? I don't think its a good design to rely on the client to handle transaction semantics. I don't think its a good idea for the server to have to rely on client logic unless it really has to. All and all, my gut tells me that the current client/tx design will cause problems. I want interceptor designers in general to avoid this kind of dependency. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David Jencks Sent: Wednesday, February 19, 2003 11:02 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really good On 2003.02.19 09:37 Bill Burke wrote: What you implemented is fine. My only problem with it is that I think it is more logical to let the server decide if it needs the tx, and that I think the registration callback could be avoided (with minimal redundant client side bookkeeping) even if the decision is made on the server side. I got the impression that this implementation would also be used in the other invokers, and that made me worry about CORBA interoperability. If this approach will not be used with the IIOP invoker, I have no problem with it. Yes this was my exact worry and still is. That we'll have to have a different set of interceptors on the server side for different transports. This is unexceptable because we want each EJB to be able to listen to and service calls from different transports at the same time. David, I'm not suggesting to redesign your code, but is the design flexible enough so that we could switch to a server-side based design? Iteration is a fine thing I don't think we will have problems adapting my current design to use corba. Before we continue I think we should get a clear understanding of what is supposed to happen when the corba tx policy and the j2ee tx support disagree. Does anyone know where this is described in specs? Basically the corba design says if there is a transaction in the context it must always be transmitted and
RE: [JBoss-dev] TxInterceptor split is really really bad
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Hiram Chirino Sent: Friday, February 21, 2003 5:17 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad I have to disagree. Take a higher level look at the basics: All client proxies have a dependency on their corresponsing server side stub. You can't mix a Yes, obviously, but the old tx client proxy just stuffed the tx context in the invocation. The problem with AOP is that (at least for 1st iteration) the POJO can be accessed directly and through a proxy at the same time. yes, I can work around this by having a flag in the Invocation object on whether or not the invocation passed through a proxy, but IMHO, this is a hack. different proxys and stub types. Therefore it is ok for a client side interceptor to have a dependency on the server side interceptor. Can you describe your AOP problem in more detail. How are you going to be remoting POJO with AOP?? With a proxy? Who will create the proxy objet? 1st iteration, DynamicProxy. This is trivial since we have already done this sort of thing for EJB and how to do AOP (or how to do it wrong, depends how you look at it), is already there for us to see. Remote AOP with DP is just an iteration to me from the current EJB stuff. 2nd iteration will be with all java classes. The hard part will be how instrumentation works on the client side, how the client receives pointcuts and such. Bill Regards, Hiram --- Bill Burke [EMAIL PROTECTED] wrote: Ok, maybe I shouldn't have said fatally flawed. But again, my gut tells me that it is bad to have a dependency between server and client interceptors if it is not absolutely needed. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Bill Burke Sent: Friday, February 21, 2003 4:12 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad I've been thinking and should have posted this before. Your design is fataly flawed when I start applying it to the AOP framework. Your design assumes that there is a proxy sitting in front of everything. In AOP this is not the case. If you look at varia/src/org/jboss/aop/plugins/TxSupport.java you'll see that I had to combine the clientInvoke and serverInvoke into one method because there is no proxy object between the application code and the object instance. Ok...no problem you sayWell, think of what happens when the app developer decides to remote an AOP'd object. I will have to have 2 sets of interceptor chains and have to figure out whether the call is a remote call or local. Well, I guess I could insert a flag into the Invocation on whether the call went through a proxy or not. But do you see where I'm going? I don't think its a good design to rely on the client to handle transaction semantics. I don't think its a good idea for the server to have to rely on client logic unless it really has to. All and all, my gut tells me that the current client/tx design will cause problems. I want interceptor designers in general to avoid this kind of dependency. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David Jencks Sent: Wednesday, February 19, 2003 11:02 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really good On 2003.02.19 09:37 Bill Burke wrote: What you implemented is fine. My only problem with it is that I think it is more logical to let the server decide if it needs the tx, and that I think the registration callback could be avoided (with minimal redundant client side bookkeeping) even if the decision is made on the server side. I got the impression that this implementation would also be used in the other invokers, and that made me worry about CORBA interoperability. If this approach will not be used with the IIOP invoker, I have no problem with it. Yes this was my exact worry and still is. That we'll have to have a different set of interceptors on the server side for different transports. This is unexceptable because we want each EJB to be able to listen to and service calls from different transports at the same time. David, I'm not suggesting to redesign your code, but is the design flexible enough so that we could switch to a server-side based design? Iteration is a fine thing I don't think we will have problems adapting my current design to use corba. Before we continue I think we should get a clear understanding of what is supposed to happen when the corba tx
RE: [JBoss-dev] TxInterceptor split is really really bad
Yes - but you guys don't seem to buy into it otherwise you won't be talking about where and how tx or remoting should go into AOP. Maybe I'm missing something. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Burke Sent: Friday, February 21, 2003 6:09 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad I personally don't think AOP should have anything related to transactions, remoting, etc. I think that should be pushed up into the functional areas that apply those specific semantics to the subsystems since they are quite different depending on the subsystem (JMS, EJB, etc) and location (local,remote). Where have you been? Marc has been talking about creating an AOP framework and services on top of this framework since the fall. The whole point is to break ourselves away from EJB and isolate and abstract out distribution infrastructure even more from a coding perspective. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Friday, February 21, 2003 5:17 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad I have to disagree. Take a higher level look at the basics: All client proxies have a dependency on their corresponsing server side stub. You can't mix a different proxys and stub types. Therefore it is ok for a client side interceptor to have a dependency on the server side interceptor. Can you describe your AOP problem in more detail. How are you going to be remoting POJO with AOP?? With a proxy? Who will create the proxy objet? Regards, Hiram --- Bill Burke [EMAIL PROTECTED] wrote: Ok, maybe I shouldn't have said fatally flawed. But again, my gut tells me that it is bad to have a dependency between server and client interceptors if it is not absolutely needed. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Bill Burke Sent: Friday, February 21, 2003 4:12 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad I've been thinking and should have posted this before. Your design is fataly flawed when I start applying it to the AOP framework. Your design assumes that there is a proxy sitting in front of everything. In AOP this is not the case. If you look at varia/src/org/jboss/aop/plugins/TxSupport.java you'll see that I had to combine the clientInvoke and serverInvoke into one method because there is no proxy object between the application code and the object instance. Ok...no problem you sayWell, think of what happens when the app developer decides to remote an AOP'd object. I will have to have 2 sets of interceptor chains and have to figure out whether the call is a remote call or local. Well, I guess I could insert a flag into the Invocation on whether the call went through a proxy or not. But do you see where I'm going? I don't think its a good design to rely on the client to handle transaction semantics. I don't think its a good idea for the server to have to rely on client logic unless it really has to. All and all, my gut tells me that the current client/tx design will cause problems. I want interceptor designers in general to avoid this kind of dependency. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David Jencks Sent: Wednesday, February 19, 2003 11:02 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really good On 2003.02.19 09:37 Bill Burke wrote: What you implemented is fine. My only problem with it is that I think it is more logical to let the server decide if it needs the tx, and that I think the registration callback could be avoided (with minimal redundant client side bookkeeping) even if the decision is made on the server side. I got the impression that this implementation would also be used in the other invokers, and that made me worry about CORBA interoperability. If this approach will not be used with the IIOP invoker, I have no problem with it. Yes this was my exact worry and still is. That we'll have to have a different set of interceptors on the server side for different transports. This is unexceptable because we want each EJB to be able to listen to and service calls from different transports at the same time. David, I'm not suggesting to redesign your code, but is the design flexible enough so that we could switch to a server-side based design? Iteration is a fine thing I don't think we will have
RE: [JBoss-dev] TxInterceptor split is really really bad
Whoops, forgot to send this too. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David Jencks Sent: Friday, February 21, 2003 5:02 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad I'm getting kind of tired of what I find vague complaints without detailed explanations of the framework in which you think there might be a problem. I don't think I was vague. I gave a specific example. The same object could be accessed locally and remotely. Locally through a regular/plain Java reference. Remotely, through a proxy. Because of the way you have defined the TM interaction, the server-side tx interceptor for AOP will have to know if the invocation passed through a Proxy since the object instance can be referenced directly locally. I think remote AOP is going to need; 1. some representation of the object you are calling 2. client interceptors. For instance, to get the security context. 3. a transport mechanism 4. something on the other end of the transport mechanism to find the right target 5. server side interceptors Stop being obvious. If you disagree please explain in detail what you propose. Personally I think the AOP stuff should do this always, with a possible null transport mechanism, at least for remotable objects. Definately no null transport. This would require a proxy. This goes against the primary goal of the framework, to provide J2EE services and remoteness for plain Java objects/classes transparently. So a programmer could say, I have this ordinary Object, I want it accessible as a WebService and yet still access the object locally. For 1st iteration, I intend to require that POJOs can only be remotely accessed via a DynamicProxy. I think this is relatively trivial to implement and will allow us to get an AOP remoting framework out there pretty quickly. 2nd iteration, I want to remove this DynamicProxy requirement, but IMHO, this requires much more thought. If you agree, then I hope you will agree that there has to be some metadata on the client side to define the client interceptors and the transport. If there is some place to put metadata, why can't I use it for the tx support? Again, it has nothing to do about metadata and all about keeping the server isolated from client quirkiness. I just think your tx separation is fragile in this respect. I would like to note that my future plans for this involve method specific interceptor chains with a variety of client side and server side tx interceptors, each one performing half of the TxSupport work. No maps, just different specialized interceptors, with different interceptors per method depending on the tx support. I also think you will admit that even in aop you could have two interceptors even if both were on the server side: one to get the tx from the context if appropriate or remove it if appropriate, one to start a new tx if appropriate. But if there is a remote proxy in between, the client stuff happens twice unless I specifically check to see if there was a proxy in front of the client. BIll --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] TxInterceptor split is really really bad
I would like to note that my future plans for this involve method specific interceptor chains with a variety of client side and server side tx interceptors, each one performing half of the TxSupport work. No maps, just different specialized interceptors, with different interceptors per method depending on the tx support. H...thanks for mentioning this. The AOP framework will have to change to support his type of per method intercepiton. Currently the ClassAdvisor asks the InterceptorFactory for an instance of an Interceptor and adds it to the interceptor chain. For what you want to do, this will have to change. The InterceptorFactory should be responsible for adding interceptors to the chain. Otherwise, my isolation and separation of metadata, interceptors, and pointcuts will be broken. I also think you will admit that even in aop you could have two interceptors even if both were on the server side: one to get the tx from the context if appropriate or remove it if appropriate, one to start a new tx if appropriate. Yes, but I still have to figure out whether or not the method call went through a proxy or was a regular java method call. Bill --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] TxInterceptor split is really really good
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ole Husgaard Sent: Wednesday, February 19, 2003 9:11 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] TxInterceptor split is really really good The OTS policy only supports the equivalents of never, supports and mandatory. Since the policy is included in the address (IOR), the client knows if it needs to send a tx id along with the call. Unfortunately, the OTS policy can only be defined at the object level and not at the method level, I think. OTS only supports the equivalents of never, supports and mandatory, but this shouldn't prevent us from having a CORBA client talking to an EJB and the EJB provides support on a per method basis for Required, RequiresNew, and NotSupported. Again, this is where I think Davids design is flawed. EJBs, MBeans and later AOP should NOT have to define separate interceptor chains for the Server for each Transport mechanism. Bill --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] TxInterceptor split is really really bad
I have to disagree. Take a higher level look at the basics: All client proxies have a dependency on their corresponsing server side stub. You can't mix a Yes, obviously, but the old tx client proxy just stuffed the tx context in Orthoganal problem. The ability to have smarter client proxies that have highly coupled interations with a serverside components is a requirment that everybody will agree with. the invocation. The problem with AOP is that (at least for 1st iteration) the POJO can be accessed directly and through a proxy at the same time. This might sound a little crazy... but how about allowing multiple server-side interceptor stacks per object? One for local access, one for stuff over IIOP (that does tx the ots way), one for stuff over JRMP etc. yes, I can work around this by having a flag in the Invocation object on whether or not the invocation passed through a proxy, but IMHO, this is a hack. yes. I am starting to agree. different proxys and stub types. Therefore it is ok for a client side interceptor to have a dependency on the server side interceptor. Can you describe your AOP problem in more detail. How are you going to be remoting POJO with AOP?? With a proxy? Who will create the proxy objet? 1st iteration, DynamicProxy. This is trivial since we have already done this sort of thing for EJB and how to do AOP (or how to do it wrong, depends how you look at it), is already there for us to see. Remote AOP with DP is just an iteration to me from the current EJB stuff. 2nd iteration will be with all java classes. The hard part will be how instrumentation works on the client side, how the client receives pointcuts and such. In either case, I'm more intersted in WHO will be responsible creaing proxy objects?? Will it be automatic done when the object is serialized? Or will the application have to make an API call to get a proxy?? Regards, Hiram Bill Regards, Hiram --- Bill Burke [EMAIL PROTECTED] wrote: Ok, maybe I shouldn't have said fatally flawed. But again, my gut tells me that it is bad to have a dependency between server and client interceptors if it is not absolutely needed. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Bill Burke Sent: Friday, February 21, 2003 4:12 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad I've been thinking and should have posted this before. Your design is fataly flawed when I start applying it to the AOP framework. Your design assumes that there is a proxy sitting in front of everything. In AOP this is not the case. If you look at varia/src/org/jboss/aop/plugins/TxSupport.java you'll see that I had to combine the clientInvoke and serverInvoke into one method because there is no proxy object between the application code and the object instance. Ok...no problem you sayWell, think of what happens when the app developer decides to remote an AOP'd object. I will have to have 2 sets of interceptor chains and have to figure out whether the call is a remote call or local. Well, I guess I could insert a flag into the Invocation on whether the call went through a proxy or not. But do you see where I'm going? I don't think its a good design to rely on the client to handle transaction semantics. I don't think its a good idea for the server to have to rely on client logic unless it really has to. All and all, my gut tells me that the current client/tx design will cause problems. I want interceptor designers in general to avoid this kind of dependency. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David Jencks Sent: Wednesday, February 19, 2003 11:02 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really good On 2003.02.19 09:37 Bill Burke wrote: What you implemented is fine. My only problem with it is that I think it is more logical to let the server decide if it needs the tx, and that I think the registration callback could be avoided (with minimal redundant client side bookkeeping) even if the decision is made on the server side. I got the impression that this implementation would also be used in the other invokers, and that made me worry about CORBA interoperability. If this approach will not be used with the IIOP invoker, I have no problem with it. Yes this was my exact worry and still is. That we'll have to have a different set of interceptors on the server side for different
RE: [JBoss-dev] (no subject)
Thanks. Sorry for this. +1 Guiness for me ;-) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jeremy Boynes Sent: Sunday, February 16, 2003 8:14 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] (no subject) This should be fixed now. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Jencks Sent: Sunday, February 16, 2003 9:48 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [JBoss-dev] (no subject) there appear to be problems with the InvocationResponse and cmp2 in jb4. Quite a few (e.g. cmp2 commerce) tests are failing apparently due to an InvocationResponse object being supplied as a pk value: 2003-02-16 11:55:52,592 DEBUG [org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreEntityCommand.OrderEJB] Executing SQL: UPDATE ORDER_DATA SET SHIPPING_ADDRESS=? WHERE ORDER_NUMBER=? 2003-02-16 11:55:52,593 ERROR [org.jboss.ejb.plugins.LogInterceptor] EJBException, causedBy: java.sql.SQLException: Wrong data type: For input string: [EMAIL PROTECTED] at org.hsqldb.Trace.getError(Unknown Source) at org.hsqldb.Trace.error(Unknown Source) at org.hsqldb.Column.convertObject(Unknown Source) at org.hsqldb.jdbcPreparedStatement.setObject(Unknown Source) at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.setOb ject(WrappedPreparedStatement.java:607) at org.jboss.ejb.plugins.cmp.jdbc.JDBCUtil.setParameter(JDBCUtil. java:278) at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBrid ge.setArgumentParameters(JDBCAbstractCMPFieldBridge.java:301) at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBrid ge.setPrimaryKeyParameters(JDBCAbstractCMPFieldBridge.java:289) at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCEntityBridge.setPrim aryKeyParameters(JDBCEntityBridge.java:581) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreEntityCommand.execute( JDBCStoreEntityCommand.java:117) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.storeEntity(JD BCStoreManager.java:614) at org.jboss.ejb.entity.CMPInterceptor.storeEntity(CMPInterceptor .java:218) Perhaps someone who knows how this area works better than I could fix this. thanks david jencks --- 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: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] TxInterceptor split is really really bad
--- Bill Burke [EMAIL PROTECTED] wrote: I would like to note that my future plans for this involve method specific interceptor chains with a variety of client side and server side tx interceptors, each one performing half of the TxSupport work. No maps, just different specialized interceptors, with different interceptors per method depending on the tx support. H...thanks for mentioning this. The AOP framework will have to change to support his type of per method intercepiton. Currently the ClassAdvisor asks the InterceptorFactory for an instance of an Interceptor and adds it to the interceptor chain. For what you want to do, this will have to change. The InterceptorFactory should be responsible for adding interceptors to the chain. Otherwise, my isolation and separation of metadata, interceptors, and pointcuts will be broken. I don't think that you model would be too broken. His interceptors should only hav to implement the org.jboss.aop.InvocationFilterInterceptor interface: boolean intercepts(Invocation invocation); The org.jboss.aop.Invocation.invokeNext() will skip over interceptors that do not interested the invocation. Currently invokeNext() interogates the intercetors on every invocation, but I think that we should be able to keep a per Invocation interceptor stack cache so that we can skip the interogation after the first method call. I also think you will admit that even in aop you could have two interceptors even if both were on the server side: one to get the tx from the context if appropriate or remove it if appropriate, one to start a new tx if appropriate. Yes, but I still have to figure out whether or not the method call went through a proxy or was a regular java method call. Bill --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] TxInterceptor split is really really bad
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jeff Haynie Sent: Friday, February 21, 2003 6:15 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad Yes - but you guys don't seem to buy into it otherwise you won't be talking about where and how tx or remoting should go into AOP. Maybe I'm missing something. I'm not understanding you. I certainly buy into it and am implementing stuff (albeit slowly). Whether you and David buy into it is irrelevent. The vision is set. THis is where we're going. The whole point is isolation and being able to dynamically remote or not remote with any protocol you want. IMHO, Davids implementation for tx right now doesn't allow for this isolation. He disagrees. So what? We disagree. Eventually it will all flush out and either David and/or I will end up rewriting everything. My bet David gets there first since I've got A.D.D. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Burke Sent: Friday, February 21, 2003 6:09 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad I personally don't think AOP should have anything related to transactions, remoting, etc. I think that should be pushed up into the functional areas that apply those specific semantics to the subsystems since they are quite different depending on the subsystem (JMS, EJB, etc) and location (local,remote). Where have you been? Marc has been talking about creating an AOP framework and services on top of this framework since the fall. The whole point is to break ourselves away from EJB and isolate and abstract out distribution infrastructure even more from a coding perspective. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Friday, February 21, 2003 5:17 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad I have to disagree. Take a higher level look at the basics: All client proxies have a dependency on their corresponsing server side stub. You can't mix a different proxys and stub types. Therefore it is ok for a client side interceptor to have a dependency on the server side interceptor. Can you describe your AOP problem in more detail. How are you going to be remoting POJO with AOP?? With a proxy? Who will create the proxy objet? Regards, Hiram --- Bill Burke [EMAIL PROTECTED] wrote: Ok, maybe I shouldn't have said fatally flawed. But again, my gut tells me that it is bad to have a dependency between server and client interceptors if it is not absolutely needed. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Bill Burke Sent: Friday, February 21, 2003 4:12 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad I've been thinking and should have posted this before. Your design is fataly flawed when I start applying it to the AOP framework. Your design assumes that there is a proxy sitting in front of everything. In AOP this is not the case. If you look at varia/src/org/jboss/aop/plugins/TxSupport.java you'll see that I had to combine the clientInvoke and serverInvoke into one method because there is no proxy object between the application code and the object instance. Ok...no problem you sayWell, think of what happens when the app developer decides to remote an AOP'd object. I will have to have 2 sets of interceptor chains and have to figure out whether the call is a remote call or local. Well, I guess I could insert a flag into the Invocation on whether the call went through a proxy or not. But do you see where I'm going? I don't think its a good design to rely on the client to handle transaction semantics. I don't think its a good idea for the server to have to rely on client logic unless it really has to. All and all, my gut tells me that the current client/tx design will cause problems. I want interceptor designers in general to avoid this kind of dependency. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David Jencks Sent: Wednesday, February 19, 2003 11:02 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really good On 2003.02.19 09:37 Bill Burke wrote: What you implemented is fine. My only problem with it is that I think it is more logical to let the server decide if it needs the tx, and that I think the registration callback could be avoided
RE: [JBoss-dev] TxInterceptor split is really really bad
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Hiram Chirino Sent: Friday, February 21, 2003 6:30 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad I have to disagree. Take a higher level look at the basics: All client proxies have a dependency on their corresponsing server side stub. You can't mix a Yes, obviously, but the old tx client proxy just stuffed the tx context in Orthoganal problem. The ability to have smarter client proxies that have highly coupled interations with a serverside components is a requirment that everybody will agree with. the invocation. The problem with AOP is that (at least for 1st iteration) the POJO can be accessed directly and through a proxy at the same time. This might sound a little crazy... but how about allowing multiple server-side interceptor stacks per object? One for local access, one for stuff over IIOP (that does tx the ots way), one for stuff over JRMP etc. In the long run, maybe this can't be avoided, but I would like to avoid it. yes, I can work around this by having a flag in the Invocation object on whether or not the invocation passed through a proxy, but IMHO, this is a hack. yes. I am starting to agree. different proxys and stub types. Therefore it is ok for a client side interceptor to have a dependency on the server side interceptor. Can you describe your AOP problem in more detail. How are you going to be remoting POJO with AOP?? With a proxy? Who will create the proxy objet? 1st iteration, DynamicProxy. This is trivial since we have already done this sort of thing for EJB and how to do AOP (or how to do it wrong, depends how you look at it), is already there for us to see. Remote AOP with DP is just an iteration to me from the current EJB stuff. 2nd iteration will be with all java classes. The hard part will be how instrumentation works on the client side, how the client receives pointcuts and such. In either case, I'm more intersted in WHO will be responsible creaing proxy objects?? Will it be automatic done when the object is serialized? Or will the application have to make an API call to get a proxy?? 1st iteration, API: Take a look at how EJB does it and how it works with multiple invokers. This is the approach I will take. I hope to iterate better and cleaner this time around though. Bill Regards, Hiram Bill Regards, Hiram --- Bill Burke [EMAIL PROTECTED] wrote: Ok, maybe I shouldn't have said fatally flawed. But again, my gut tells me that it is bad to have a dependency between server and client interceptors if it is not absolutely needed. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Bill Burke Sent: Friday, February 21, 2003 4:12 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad I've been thinking and should have posted this before. Your design is fataly flawed when I start applying it to the AOP framework. Your design assumes that there is a proxy sitting in front of everything. In AOP this is not the case. If you look at varia/src/org/jboss/aop/plugins/TxSupport.java you'll see that I had to combine the clientInvoke and serverInvoke into one method because there is no proxy object between the application code and the object instance. Ok...no problem you sayWell, think of what happens when the app developer decides to remote an AOP'd object. I will have to have 2 sets of interceptor chains and have to figure out whether the call is a remote call or local. Well, I guess I could insert a flag into the Invocation on whether the call went through a proxy or not. But do you see where I'm going? I don't think its a good design to rely on the client to handle transaction semantics. I don't think its a good idea for the server to have to rely on client logic unless it really has to. All and all, my gut tells me that the current client/tx design will cause problems. I want interceptor designers in general to avoid this kind of dependency. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David Jencks Sent: Wednesday, February 19, 2003 11:02 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really good On 2003.02.19 09:37 Bill Burke wrote: What you implemented is fine. My only problem with it is that I think it is more logical to
RE: [JBoss-dev] TxInterceptor split is really really bad
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Hiram Chirino Sent: Friday, February 21, 2003 6:44 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad --- Bill Burke [EMAIL PROTECTED] wrote: I would like to note that my future plans for this involve method specific interceptor chains with a variety of client side and server side tx interceptors, each one performing half of the TxSupport work. No maps, just different specialized interceptors, with different interceptors per method depending on the tx support. H...thanks for mentioning this. The AOP framework will have to change to support his type of per method intercepiton. Currently the ClassAdvisor asks the InterceptorFactory for an instance of an Interceptor and adds it to the interceptor chain. For what you want to do, this will have to change. The InterceptorFactory should be responsible for adding interceptors to the chain. Otherwise, my isolation and separation of metadata, interceptors, and pointcuts will be broken. I don't think that you model would be too broken. His interceptors should only hav to implement the org.jboss.aop.InvocationFilterInterceptor interface: boolean intercepts(Invocation invocation); The org.jboss.aop.Invocation.invokeNext() will skip over interceptors that do not interested the invocation. Currently invokeNext() interogates the intercetors on every invocation, but I think that we should be able to keep a per Invocation interceptor stack cache so that we can skip the interogation after the first method call. That's not the issue. The issue is configuration. He wants to avoid sending over metadata about the method/tx bindings. TO do this he creates a Mandatory.java class and attaches it to the method. You see now? Actually David, you actually have almost the same memory footprint. WIthout per method , you have one instance of the Tx interceptor. WIth, you have an instance per interceptor. Almost the same as a hashmap of methodnames and strings identifying the tx attribute. Bill --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] TxInterceptor split is really really bad
Oh, I buy into it - and I'm neither for OR against what David is saying. I'm merely saying you should separate the concerns - but it seems like that is obvious and redudant (although not so apparent with all the back in forth) to you. As you know, I don't work for Jboss Group. I'm just merely trying to help out on my own *free time* and try and help make this a better product with what little value I can add. Sorry I stepped into the flames. I was hoping to enlighten a little bit to the fact that you could push some of this stuff into the remoting stuff that tom and I worked on. Jeff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jeff Haynie Sent: Friday, February 21, 2003 6:15 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad Yes - but you guys don't seem to buy into it otherwise you won't be talking about where and how tx or remoting should go into AOP. Maybe I'm missing something. I'm not understanding you. I certainly buy into it and am implementing stuff (albeit slowly). Whether you and David buy into it is irrelevent. The vision is set. THis is where we're going. The whole point is isolation and being able to dynamically remote or not remote with any protocol you want. IMHO, Davids implementation for tx right now doesn't allow for this isolation. He disagrees. So what? We disagree. Eventually it will all flush out and either David and/or I will end up rewriting everything. My bet David gets there first since I've got A.D.D. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Burke Sent: Friday, February 21, 2003 6:09 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad I personally don't think AOP should have anything related to transactions, remoting, etc. I think that should be pushed up into the functional areas that apply those specific semantics to the subsystems since they are quite different depending on the subsystem (JMS, EJB, etc) and location (local,remote). Where have you been? Marc has been talking about creating an AOP framework and services on top of this framework since the fall. The whole point is to break ourselves away from EJB and isolate and abstract out distribution infrastructure even more from a coding perspective. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Friday, February 21, 2003 5:17 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad I have to disagree. Take a higher level look at the basics: All client proxies have a dependency on their corresponsing server side stub. You can't mix a different proxys and stub types. Therefore it is ok for a client side interceptor to have a dependency on the server side interceptor. Can you describe your AOP problem in more detail. How are you going to be remoting POJO with AOP?? With a proxy? Who will create the proxy objet? Regards, Hiram --- Bill Burke [EMAIL PROTECTED] wrote: Ok, maybe I shouldn't have said fatally flawed. But again, my gut tells me that it is bad to have a dependency between server and client interceptors if it is not absolutely needed. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Bill Burke Sent: Friday, February 21, 2003 4:12 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad I've been thinking and should have posted this before. Your design is fataly flawed when I start applying it to the AOP framework. Your design assumes that there is a proxy sitting in front of everything. In AOP this is not the case. If you look at varia/src/org/jboss/aop/plugins/TxSupport.java you'll see that I had to combine the clientInvoke and serverInvoke into one method because there is no proxy object between the application code and the object instance. Ok...no problem you sayWell, think of what happens when the app developer decides to remote an AOP'd object. I will have to have 2 sets of interceptor chains and have to figure out whether the call is a remote call or local. Well, I guess I could insert a flag into the Invocation on whether the call went through a proxy or not. But do you see where I'm going? I don't think its a good design to rely on the client to handle transaction semantics. I don't think its a good idea for the server to have to rely on client logic unless it really has to. All and all, my gut tells me that the current client/tx design will cause problems. I want interceptor designers in general to avoid this
RE: [JBoss-dev] TxInterceptor split is really really bad
--- Bill Burke [EMAIL PROTECTED] wrote: This might sound a little crazy... but how about allowing multiple server-side interceptor stacks per object? One for local access, one for stuff over IIOP (that does tx the ots way), one for stuff over JRMP etc. In the long run, maybe this can't be avoided, but I would like to avoid it. What are the problems related in implementing this?? Regards. Hiram __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Verifier problems
I'm working on fixing the exception tests and I have run into a problem with the verifier. I am getting the following warning that is causing the deployment to fail: Bean : ExceptionTesterEJB Method : public abstract void ejbExceptionInStore() throws Exception Section: 7.10.7 Warning: The methods in the local interface must not include java.rmi.RemoteException in their throws clause. I don't think they wanted to exclude 'throws Exception' from a declaration. This is really a grey area of the spec. Who is maintaining this code? What do you think? -dain --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed
= ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net FOR DETAILS= = JAVA VERSION DETAILS java version 1.3.1_06 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_06-b01) Java HotSpot(TM) Server VM (build 1.3.1_06-b01, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE [mkdir] Created dir: /home/jboss/jbossci/jboss-head/build/output/testbuild/server/all/deploy [copy] Copying 1 file to /home/jboss/jbossci/jboss-head/build/output/testbuild/server/all/deploy [copy] Copying 1 file to /home/jboss/jbossci/jboss-head/build/output/testbuild/client == == == Executing 'most' in module 'transaction'... == == compile-mbean-sources: [mkdir] Created dir: /home/jboss/jbossci/jboss-head/transaction/output/gen/classes [mkdir] Created dir: /home/jboss/jbossci/jboss-head/transaction/output/etc Running jbossxmbean/ Generating output for 'org.jboss.tm.JBossXidFactory' using template file 'jar:file:/home/jboss/jbossci/jboss-head/thirdparty/xdoclet-xdoclet/lib/xdoclet-jboss-module-jb4.jar!/xdoclet/modules/jboss/jmx/resources/jbossmx-xml-descriptor.xdt'. Generating output for 'org.jboss.tm.NoLogTxLogger' using template file 'jar:file:/home/jboss/jbossci/jboss-head/thirdparty/xdoclet-xdoclet/lib/xdoclet-jboss-module-jb4.jar!/xdoclet/modules/jboss/jmx/resources/jbossmx-xml-descriptor.xdt'. Generating output for 'org.jboss.tm.UserTransactionImpl' using template file 'jar:file:/home/jboss/jbossci/jboss-head/thirdparty/xdoclet-xdoclet/lib/xdoclet-jboss-module-jb4.jar!/xdoclet/modules/jboss/jmx/resources/jbossmx-xml-descriptor.xdt'. Generating output for 'org.jboss.tm.SerializingTxLogger' using template file 'jar:file:/home/jboss/jbossci/jboss-head/thirdparty/xdoclet-xdoclet/lib/xdoclet-jboss-module-jb4.jar!/xdoclet/modules/jboss/jmx/resources/jbossmx-xml-descriptor.xdt'. Generating output for 'org.jboss.tm.TransactionManagerService' using template file 'jar:file:/home/jboss/jbossci/jboss-head/thirdparty/xdoclet-xdoclet/lib/xdoclet-jboss-module-jb4.jar!/xdoclet/modules/jboss/jmx/resources/jbossmx-xml-descriptor.xdt'. Running jbossxmlservicetemplate/ Generating output 'transaction-service.xml' using template file 'jar:file:/home/jboss/jbossci/jboss-head/thirdparty/xdoclet-xdoclet/lib/xdoclet-jboss-module-jb4.jar!/xdoclet/modules/jboss/jmx/resources/jboss-service-template.xdt'. INFO:Some classes refer to other classes that were not found among the sources or on the classpath. (Perhaps the referred class doesn't exist? Hasn't been generated yet?) The referring classes do not import any fully qualified classes matching these classes. However, since no packages are imported, xjavadoc has assumed that the referred classes belong to the same package as the referring class. The classes are: org.jboss.system.client.Client -- ClientMBean qualified to ClientMBean org.jboss.tm.UserTransactionStartedListener -- EventListener qualified to EventListener Running null/ _default:compile-classes: [mkdir] Created dir: /home/jboss/jbossci/jboss-head/transaction/output/classes [depend] Deleted 0 out of date files in 0 seconds [javac] Compiling 23 source files to /home/jboss/jbossci/jboss-head/transaction/output/classes /home/jboss/jbossci/jboss-head/transaction/src/main/org/jboss/tm/JBossXidFactory.java:20: cannot resolve symbol symbol : class InstanceID location: package remote import org.jboss.mx.remote.InstanceID; ^ /home/jboss/jbossci/jboss-head/transaction/src/main/org/jboss/tm/JBossXidFactory.java:102: cannot resolve symbol symbol : variable InstanceID location: class org.jboss.tm.JBossXidFactory baseGlobalId = InstanceID.getID(getServer());//InetAddress.getLocalHost().getHostName() + /; ^ 2 errors BUILD FAILED file:/home/jboss/jbossci/jboss-head/transaction/../tools/etc/buildfragments/targets.ent:45: Compile failed; see the compiler error output for details. Total time: 1 minute 18 seconds --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Verifier problems
Only RemoteException or its subclasses should be flagged as errors. There is nothing wrong with a local interface throwing a checked Exception. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Dain Sundstrom [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, February 21, 2003 5:42 PM Subject: [JBoss-dev] Verifier problems I'm working on fixing the exception tests and I have run into a problem with the verifier. I am getting the following warning that is causing the deployment to fail: Bean : ExceptionTesterEJB Method : public abstract void ejbExceptionInStore() throws Exception Section: 7.10.7 Warning: The methods in the local interface must not include java.rmi.RemoteException in their throws clause. I don't think they wanted to exclude 'throws Exception' from a declaration. This is really a grey area of the spec. Who is maintaining this code? What do you think? -dain --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread
On 2003.02.21 18:58 Bill Burke wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Hiram Chirino Sent: Friday, February 21, 2003 6:44 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad --- Bill Burke [EMAIL PROTECTED] wrote: I would like to note that my future plans for this involve method specific interceptor chains with a variety of client side and server side tx interceptors, each one performing half of the TxSupport work. No maps, just different specialized interceptors, with different interceptors per method depending on the tx support. H...thanks for mentioning this. The AOP framework will have to change to support his type of per method intercepiton. Currently the ClassAdvisor asks the InterceptorFactory for an instance of an Interceptor and adds it to the interceptor chain. For what you want to do, this will have to change. The InterceptorFactory should be responsible for adding interceptors to the chain. Otherwise, my isolation and separation of metadata, interceptors, and pointcuts will be broken. I don't think that you model would be too broken. His interceptors should only hav to implement the org.jboss.aop.InvocationFilterInterceptor interface: boolean intercepts(Invocation invocation); The org.jboss.aop.Invocation.invokeNext() will skip over interceptors that do not interested the invocation. Currently invokeNext() interogates the intercetors on every invocation, but I think that we should be able to keep a per Invocation interceptor stack cache so that we can skip the interogation after the first method call. Per method interceptor stacks will eliminate the need to the interceptor filter interface. That's not the issue. The issue is configuration. He wants to avoid sending over metadata about the method/tx bindings. WTF??? I want to send to the client the information about whether an exising tx needs to be sent, and as I have indicated I would like to encode this in which interceptor is in each method's client side invocation chain. Until we have method specific interceptor chains, I need a method to tx support map. TO do this he creates a Mandatory.java class and attaches it to the method. You see now? Actually David, you actually have almost the same memory footprint. As what??? WIthout per method , you have one instance of the Tx interceptor. WIth, you have an instance per interceptor. Almost the same as a hashmap of methodnames and strings identifying the tx attribute. yes, this is obvious. Maybe we have really different ideas about what will go in the interceptor stack for an aop object. I was assuming that it would go like this, just like an ejb: local aop object ci1 ci2 local invoker si1 si2 si2 actual aop object and remote aop object ci1 ci2 real invoker (transport) si1 si2 actual aop object where ci are client interceptors and si are server interceptors. This way any aop object gets the same interceptor stack no matter if it is local or remote. I don't really care if either the local or remote aop object is the actual object or some kind of proxy: I don't think it makes any difference. I don't see why the remote aop thingy can't be the actual object rather than a dynamic proxy, it's just that all the work gets tossed over to a different server. If you plan to leave out the ci's for local aop objects I want to know how you have any chance of getting even mildly similar behavior between local and remote versions. === corba My current (limited) understanding of corba tx support leads me to believe that any working corba implementation will use the corba tx policies to their fullest advantage and will have already established and enlisted a transaction branch on the corba tx manager whenever it sends a transaction with an invocation. We can't do anything about this, so we can't save it some work if it happens to be calling a method (not supported or requires new) that won't use the tx that was sent. I assume we can't install any kind of real client side interceptors in corba, we just have to take what is sent to us. If this is wrong please speak up. Therefore, we have to duplicate the functionality of the client side interceptors somewhere on the server side in the iiop invoker. If we don't do this we will get the wrong semantics. I don't know exactly how the iiop invoker works, but I would hope that we could set it up so that it looks like: outside world something corba and proxy-like ci1 ci2 some kind of invoker-like thing si1 si2 actual target object This is really similar to a local ejb call, except it may not start with a dynamic proxy ( I don't know what it would start with). Also I don't know it the invoker-like thing would do nothing or something.
Re: [JBoss-dev] TxInterceptor split is really really bad
Jeff, Don't let these guys push you around. Bill's just in a pissy mood today. -dain On Friday, February 21, 2003, at 06:01 PM, Jeff Haynie wrote: Oh, I buy into it - and I'm neither for OR against what David is saying. I'm merely saying you should separate the concerns - but it seems like that is obvious and redudant (although not so apparent with all the back in forth) to you. As you know, I don't work for Jboss Group. I'm just merely trying to help out on my own *free time* and try and help make this a better product with what little value I can add. Sorry I stepped into the flames. I was hoping to enlighten a little bit to the fact that you could push some of this stuff into the remoting stuff that tom and I worked on. Jeff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jeff Haynie Sent: Friday, February 21, 2003 6:15 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad Yes - but you guys don't seem to buy into it otherwise you won't be talking about where and how tx or remoting should go into AOP. Maybe I'm missing something. I'm not understanding you. I certainly buy into it and am implementing stuff (albeit slowly). Whether you and David buy into it is irrelevent. The vision is set. THis is where we're going. The whole point is isolation and being able to dynamically remote or not remote with any protocol you want. IMHO, Davids implementation for tx right now doesn't allow for this isolation. He disagrees. So what? We disagree. Eventually it will all flush out and either David and/or I will end up rewriting everything. My bet David gets there first since I've got A.D.D. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Burke Sent: Friday, February 21, 2003 6:09 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad I personally don't think AOP should have anything related to transactions, remoting, etc. I think that should be pushed up into the functional areas that apply those specific semantics to the subsystems since they are quite different depending on the subsystem (JMS, EJB, etc) and location (local,remote). Where have you been? Marc has been talking about creating an AOP framework and services on top of this framework since the fall. The whole point is to break ourselves away from EJB and isolate and abstract out distribution infrastructure even more from a coding perspective. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Friday, February 21, 2003 5:17 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad I have to disagree. Take a higher level look at the basics: All client proxies have a dependency on their corresponsing server side stub. You can't mix a different proxys and stub types. Therefore it is ok for a client side interceptor to have a dependency on the server side interceptor. Can you describe your AOP problem in more detail. How are you going to be remoting POJO with AOP?? With a proxy? Who will create the proxy objet? Regards, Hiram --- Bill Burke [EMAIL PROTECTED] wrote: Ok, maybe I shouldn't have said fatally flawed. But again, my gut tells me that it is bad to have a dependency between server and client interceptors if it is not absolutely needed. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Bill Burke Sent: Friday, February 21, 2003 4:12 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad I've been thinking and should have posted this before. Your design is fataly flawed when I start applying it to the AOP framework. Your design assumes that there is a proxy sitting in front of everything. In AOP this is not the case. If you look at varia/src/org/jboss/aop/plugins/TxSupport.java you'll see that I had to combine the clientInvoke and serverInvoke into one method because there is no proxy object between the application code and the object instance. Ok...no problem you sayWell, think of what happens when the app developer decides to remote an AOP'd object. I will have to have 2 sets of interceptor chains and have to figure out whether the call is a remote call or local. Well, I guess I could insert a flag into the Invocation on whether the call went through a proxy or not. But do you see where I'm going? I don't think its a good design to rely on the client to handle transaction semantics. I don't think its a good idea for the server to have to rely on client logic unless it really has to. All and all, my gut tells me that the current client/tx design will cause problems. I want interceptor designers in general to avoid this kind of dependency. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David Jencks Sent: Wednesday, February
[JBoss-dev] Automated JBoss(Branch_3_2 WonderLand) Testsuite Results: 21-February-2003
JBoss daily test results SUMMARY Number of tests run: 1102 Successful tests: 1095 Errors:7 Failures: 0 [time of test: 2003-02-22.02-24 GMT] [java.version: 1.3.1_05] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.3.1_05-b02] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Windows 2000] [os.arch: x86] [os.version: 5.0] Useful resources: - http://users.jboss.org/~starksm/Branch_3_2/2003-02-22.02-24 for the junit report of this test. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS Suite: InvocationLayerStressTestCase Test: testOIL2MutliSessionOneConnection(org.jboss.test.jbossmq.perf.InvocationLayerStressTestCase) Type:error Exception: java.lang.InternalError Message: Test timeout - Suite: SecurityUnitTestCase Test:runValidDynDurSub(org.jboss.test.jbossmq.test.SecurityUnitTestCase) Type:error Exception: java.lang.InternalError Message: Test timeout - Suite: DeployXMBeanUnitTestCase Test:testDeployUserXMBean(org.jboss.test.jmx.test.DeployXMBeanUnitTestCase) Type:error Exception: org.jboss.deployment.DeploymentException Message: create operation failed for package file:/C:/cvs/JBoss3.2/jboss-3.2/testsuite/output/lib/user-xmbean.sar; - nested throwable: (org.jboss.deployment.DeploymentException: Error parsing the XML file: org.xml.sax.SAXParseException: Attribute persistPolicy with value Never must have a value from the list NEVER ONUPDATE NOMOREOFTENTHAN ONTIMER .; - nested throwable: (javax.management.NotCompliantMBeanException: Error parsing the XML file: org.xml.sax.SAXParseException: Attribute persistPolicy with value Never must have a value from the list NEVER ONUPDATE NOMOREOFTENTHAN ONTIMER .)) - Suite: MissingClassUnitTestCase Test: testDeployServiceWithoutClass(org.jboss.test.jmx.test.MissingClassUnitTestCase) Type:error Exception: org.jboss.deployment.DeploymentException Message: create operation failed for package file:/C:/cvs/JBoss3.2/jboss-3.2/testsuite/output/lib/missingclass-service.xml; - nested throwable: (javax.management.InstanceNotFoundException: jboss.test:name=missingclasstest is not registered.) - Suite: JSR77SpecUnitTestCase Test:testNavigation(org.jboss.test.management.test.JSR77SpecUnitTestCase) Type:error Exception: javax.management.InstanceNotFoundException Message: jboss.management.local:J2EEApplication=cts-v1cmp.ear,J2EEServer=Local,j2eeType=EJBModule,name=cts-v1cmp.jar is not registered. - Suite: HttpsUnitTestCase Test:testJSSE(org.jboss.test.security.test.HttpsUnitTestCase) Type:error Exception: java.net.BindException Message: Address in use: JVM_Bind - Suite: SRPUnitTestCase Test:testEchoArgs(org.jboss.test.security.test.SRPUnitTestCase) Type:error Exception: java.lang.reflect.UndeclaredThrowableException Message: - --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] TxInterceptor split is really really bad
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jeff Haynie Sent: Friday, February 21, 2003 7:02 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad Oh, I buy into it - and I'm neither for OR against what David is saying. I'm merely saying you should separate the concerns - but it seems like that is obvious and redudant (although not so apparent with all the back in forth) to you. As you know, I don't work for Jboss Group. I'm just merely trying to help out on my own *free time* and try and help make this a better product with what little value I can add. As Dain said, just ignore flames and don't let them deter you from entering the conversation. (Yes I flamed you, and no, I'm not sorry. But I'd still go out for beers if you're still coming to Boston.) Sorry I stepped into the flames. I was hoping to enlighten a little bit to the fact that you could push some of this stuff into the remoting stuff that tom and I worked on. Tx propagation can be pushed to a generic remoting framework/object if the underlying transport supports it. Class/Interface Metadata can't. Bill Jeff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jeff Haynie Sent: Friday, February 21, 2003 6:15 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad Yes - but you guys don't seem to buy into it otherwise you won't be talking about where and how tx or remoting should go into AOP. Maybe I'm missing something. I'm not understanding you. I certainly buy into it and am implementing stuff (albeit slowly). Whether you and David buy into it is irrelevent. The vision is set. THis is where we're going. The whole point is isolation and being able to dynamically remote or not remote with any protocol you want. IMHO, Davids implementation for tx right now doesn't allow for this isolation. He disagrees. So what? We disagree. Eventually it will all flush out and either David and/or I will end up rewriting everything. My bet David gets there first since I've got A.D.D. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Burke Sent: Friday, February 21, 2003 6:09 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad I personally don't think AOP should have anything related to transactions, remoting, etc. I think that should be pushed up into the functional areas that apply those specific semantics to the subsystems since they are quite different depending on the subsystem (JMS, EJB, etc) and location (local,remote). Where have you been? Marc has been talking about creating an AOP framework and services on top of this framework since the fall. The whole point is to break ourselves away from EJB and isolate and abstract out distribution infrastructure even more from a coding perspective. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Friday, February 21, 2003 5:17 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad I have to disagree. Take a higher level look at the basics: All client proxies have a dependency on their corresponsing server side stub. You can't mix a different proxys and stub types. Therefore it is ok for a client side interceptor to have a dependency on the server side interceptor. Can you describe your AOP problem in more detail. How are you going to be remoting POJO with AOP?? With a proxy? Who will create the proxy objet? Regards, Hiram --- Bill Burke [EMAIL PROTECTED] wrote: Ok, maybe I shouldn't have said fatally flawed. But again, my gut tells me that it is bad to have a dependency between server and client interceptors if it is not absolutely needed. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Bill Burke Sent: Friday, February 21, 2003 4:12 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad I've been thinking and should have posted this before. Your design is fataly flawed when I start applying it to the AOP framework. Your design assumes that there is a proxy sitting in front of everything. In AOP this is not the case. If you look at varia/src/org/jboss/aop/plugins/TxSupport.java you'll see that I had to combine the clientInvoke and serverInvoke into one method because there is no proxy object between the application code and the object instance. Ok...no problem you sayWell, think of what happens when the app
RE: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David Jencks Sent: Friday, February 21, 2003 9:26 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread On 2003.02.21 18:58 Bill Burke wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Hiram Chirino Sent: Friday, February 21, 2003 6:44 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad --- Bill Burke [EMAIL PROTECTED] wrote: I would like to note that my future plans for this involve method specific interceptor chains with a variety of client side and server side tx interceptors, each one performing half of the TxSupport work. No maps, just different specialized interceptors, with different interceptors per method depending on the tx support. H...thanks for mentioning this. The AOP framework will have to change to support his type of per method intercepiton. Currently the ClassAdvisor asks the InterceptorFactory for an instance of an Interceptor and adds it to the interceptor chain. For what you want to do, this will have to change. The InterceptorFactory should be responsible for adding interceptors to the chain. Otherwise, my isolation and separation of metadata, interceptors, and pointcuts will be broken. I don't think that you model would be too broken. His interceptors should only hav to implement the org.jboss.aop.InvocationFilterInterceptor interface: boolean intercepts(Invocation invocation); The org.jboss.aop.Invocation.invokeNext() will skip over interceptors that do not interested the invocation. Currently invokeNext() interogates the intercetors on every invocation, but I think that we should be able to keep a per Invocation interceptor stack cache so that we can skip the interogation after the first method call. Per method interceptor stacks will eliminate the need to the interceptor filter interface. Implementation detail. Who cares. That's not the issue. The issue is configuration. He wants to avoid sending over metadata about the method/tx bindings. WTF??? I want to send to the client the information about whether an exising tx needs to be sent, and as I have indicated I would like to encode this in which interceptor is in each method's client side invocation chain. Until we have method specific interceptor chains, I need a method to tx support map. Actually I thought of another reason why having a per method interceptor for TX is bad. You wouldn't be able to override the behavior at runtime. One of the goals I have for the AOP framework and JBOss in general is the ability to override behavior for one and only one method call. Maybe you want to programatically decide transaction boundaries for a method call. But anyways.you raise a good point that I haven't thought of even though I think per method interceptor for TX is a bad idea. In AOP I want the definition of class metadata and interceptions(pointcuts) to remain isolated. Currently the ClassAdvisor asks the interceptor factory for an instance of an interceptor and adds it to the chain. I need to switch this around so that the factory has control on how interceptors get attached to the chain instead. This is so I can define chains easily for a whole range of classes : interceptor-pointcut name=j2ee class=com.* interceptors interceptor factory=Tx .../ interceptor factory=Security... ... / /interceptors /interceptor-poincut Yet, be able to have per method interceptor stacks for a particular interceptor type by letting the factory handle how interceptor(s) get attached to the Class. Am I making sense? Yes? good, No? Doesn't matter, implementation detail TO do this he creates a Mandatory.java class and attaches it to the method. You see now? Actually David, you actually have almost the same memory footprint. As what??? WIthout per method , you have one instance of the Tx interceptor. WIth, you have an instance per interceptor. Almost the same as a hashmap of methodnames and strings identifying the tx attribute. yes, this is obvious. Maybe we have really different ideas about what will go in the interceptor stack for an aop object. I was assuming that it would go like this, just like an ejb: local aop object ci1 ci2 local invoker si1 si2 si2 actual aop object Remember what we're trying to do here. MyObject obj = new MyObject(...); obj.doSomeMethod(); construction is intercepted doSomeMethod is intercepted. To have a local invoker new MyObject(...) would have to create a non-dynamic proxy with MyObject. The is unacceptable because then we have to define a contract for doing AOP when
