RE: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread

[Bill Burke]

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

[Bill Burke]

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

[scott . stark]

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

[Dain Sundstrom]

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

[David Jencks]

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

[Scott M Stark]

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

[chris]

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

[Dain Sundstrom]

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

[Hiram Chirino]

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

[Jeff Haynie]

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

[Bill Burke]

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

[Bill Burke]

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

[Bill Burke]

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

[Hiram Chirino]

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

[Bill Burke]

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

[Bill Burke]

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

[Hiram Chirino]

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

[Bill Burke]

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

[Bill Burke]

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

[Jeff Haynie]

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

[Bill Burke]

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

[Bill Burke]

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

[Jeff Haynie]

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

[Hiram Chirino]

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

[David Jencks]

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

[Bill Burke]

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

[Bill Burke]

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

[scott . stark]

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

[SourceForge.net]

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

[Jeff Haynie]

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

[Jeff Haynie]

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

[Bill Burke]

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

[Jeff Haynie]

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

[SourceForge.net]

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

[Peter Antman]

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

[James Cooley]

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

[Peter Antman]

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