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 : 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(...) wo
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
[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
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, Feb
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 sim
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
[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 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 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 _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
[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 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
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 seman
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
> -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 > > > > > > > > > > > --
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] > > > > >
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] (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 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. > > > > > > > > > > >
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 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
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
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
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 h
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 > > > > transport
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 > >
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 > >
RE: [JBoss-dev] TxInterceptor split is really really bad
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 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.
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.
[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
[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=detail&atid=376685&aid=690177&group_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=detail&atid=376685&aid=690177&group_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
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 does not 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 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 does not 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 does not 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-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 does not 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-690789 ] java.net.ConnectionException when deleting a temp Q
Bugs item #690789, was opened at 2003-02-21 17:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=690789&group_id=22866 Category: JBossMQ Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: David Saslawsky (saslawsky) Assigned to: Nobody/Anonymous (nobody) Summary: java.net.ConnectionException when deleting a temp Q Initial Comment: Cut/Paste from http://www.jboss.org/forums/thread.jsp?forum=48&thread=20604&message=3739038&q=temporary#3739038 I get the same error on JBoss 3.0.4 import javax.naming.*; import javax.jms.*; import java.util.*; public class TempQ { public static void main (String[] args) throws Exception { QueueConnection conn1 = null; try { System.out.println("GET JNDI ROOT CONTEXT"); Properties prop = new Properties(); prop.put("java.naming.factory.initial", "org.jnp.interfaces.NamingContextFactory"); prop.put("java.naming.provider.url", "jnp://localhost:1099"); Context context = new InitialContext(prop); System.out.println("DO JNDI LOOKUP FOR QUEUE CONNECTION FACTORY"); QueueConnectionFactory factory = (QueueConnectionFactory) context.lookup("java:/ConnectionFactory"); System.out.println("CREATE A QUEUE CONNECTION"); conn1 = factory.createQueueConnection(); System.out.println("CREATE A QUEUE SESSION"); QueueSession session1 = conn1.createQueueSession(false, Session.AUTO_ACKNOWLEDGE); System.out.println("CREATE A TEMPORARY QUEUE"); TemporaryQueue tempQueue = session1.createTemporaryQueue(); System.out.println("DELETE THE TEMPORARY QUEUE"); tempQueue.delete(); System.out.println("END OF TEST"); } catch (Exception e) { e.printStackTrace(); } finally { if (conn1 != null) { conn1.close(); } } } } -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=690789&group_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
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 mailto:[EMAIL PROTECTED]";>James Cooley > >> */ > >> > >>public class HTTPClassLoaderServlet extends HttpServlet > >>{ > >> > >> // Constants - > >> > >> // Attributes > >> private static Logger log = Lo
Re: [JBoss-dev] Remote class loading servlet
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. 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 mailto:[EMAIL PROTECTED]";>James Cooley */ 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; boolea
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 mailto:[EMAIL PROTECTED]";>James Cooley > */ > > 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