Re: [JBoss-dev] Remote class loading servlet
Hi Dain, Scott, I wrote a servlet that accepts a request from a java.net.URLClassLoader and returns the class. AFAIK I need only support requests of the kind org/jboss/util/stream/Streams.class but the exising WebServer class also supports "SomeClassName[some/object/id]/some/file/path" I can't find where this protocol is defined elsewhere - please point me at the spec if we need to support it - I'm a bit blind as to what we need as you can see from the next question ... I created a class-loader.war and I tried running the JRMP tests with ./testsuite/build.sh -Djava.rmi.server.codebase=http://localhost:8080/class-loader/ -Dtest=jrmp test but it doesn't work and I get ERROR [JRMPInvoker] Starting failed: java.rmi.server.ExportException: Port already in use: 4447; What am I doing wrong? How can I test this. 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 --- 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-dev] [ jboss-Patches-685326 ] close XAManagedConnection when the connection is destroyed
Patches item #685326, was opened at 2003-02-12 09:16
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376687&aid=685326&group_id=22866
Category: JBossCX
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeff Gettle (jgettle)
Assigned to: Nobody/Anonymous (nobody)
Summary: close XAManagedConnection when the connection is destroyed
Initial Comment:
There is a bug in the XAManagedConnection. When the
pooled connection is destroyed, close is never called
on the XAConnection.
We use oracle and I noticed it by running a transaction
and then waiting until the connection pool tried to
removed the connection. The connection was no longer
use by jboss because I executed another transaction and
a new connection was created... however the original
connection was never closed. Below is the patch to
correct the problem.
RCS file:
/cvsroot/jboss/jbosscx/src/main/org/jboss/resource/adapter/jdbc/xa/XAManagedConnection.java,v
retrieving revision 1.3.2.1
diff -u -r1.3.2.1 XAManagedConnection.java
--- XAManagedConnection.java7 Nov 2002 21:04:19
- 1.3.2.1
+++ XAManagedConnection.java12 Feb 2003 13:51:37 -
@@ -218,5 +218,22 @@
}
+ /**
+*
+* @exception javax.resource.ResourceException
+*/
+ public void destroy() throws ResourceException
+ {
+ super.destroy();
+ try
+ {
+xaConnection.close();
+ }
+ catch (SQLException e)
+ {
+ checkException(e);
+ } // end of try-catch
+ }
+
}// XAManagedConnection
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376687&aid=685326&group_id=22866
---
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-dev] [ jboss-Bugs-685329 ] Java-Editor in Eclipse M5 does not work when JBoss-IDE inst.
Bugs item #685329, was opened at 2003-02-12 15:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=685329&group_id=22866 Category: JBoss-IDE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dr. Domagoj Cosic (domic) Assigned to: Nobody/Anonymous (nobody) Summary: Java-Editor in Eclipse M5 does not work when JBoss-IDE inst. Initial Comment: I installed jbosside1.0a_06.zip over M5 eclipse. From now on the Java Editor did not work. Already open editor windows showed a red "An error has occured when creating this editor" and an attempt to open a new one led to the error alert box "Unable to create part: foo.java". Uninstalling the plugin removed that problem too but from now on the editor font was reset to the default system font and the preferences for Java Editor Font under Workbench/Fonts/ (not Java/Editor any more in M5) to set the font size was missing. Re-installing M5 in the same directory (preserving the other plugins) solved the problem. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=685329&group_id=22866 --- 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-dev] [ jboss-Bugs-575966 ] JCA - commit failure not reported
Bugs item #575966, was opened at 2002-07-01 08:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=575966&group_id=22866 Category: JBossTX Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Paul Adams (padams) Assigned to: David Jencks (d_jencks) Summary: JCA - commit failure not reported Initial Comment: JBoss: 3.0 integrated with tomcat JDK: 1.4.0 OS: Win2K Connector deployed with LocalTransaction support. Failure to commit a transaction is not reported to the client. Logged stack trace below: 08:52:28,927 WARN [TxCapsule] XAException: tx=XidImpl [FormatId=257, GlobalId=padams//0, BranchQual=] errorCode=XA_UNKNOWN(0) javax.transaction.xa.XAException: could not commit local txjavax.resource.ResourceExceptio n: Server.InternalServerError:failure to commit at org.jboss.resource.connectionmanager.LocalTxConnectionManager$LocalConnectionEv entListener.commit(LocalTxConnectionManager.java:563) at org.jboss.tm.TxCapsule.commitResources(TxCapsule.java:1656) at org.jboss.tm.TxCapsule.commit(TxCapsule.java:357) at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:74) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.jav a:190) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:61) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:166) at org.jboss.ejb.StatefulSessionContainer.invoke(StatefulSessionContainer.java:380 ) at org.jboss.ejb.Container.invoke(Container.java:705) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491) at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:362) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.ja va:25) at java.lang.reflect.Method.invoke(Method.java:324) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261) at sun.rmi.transport.Transport$1.run(Transport.java:148) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:144) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701) at java.lang.Thread.run(Thread.java:536) -- >Comment By: Paul Adams (padams) Date: 2003-02-12 09:02 Message: Logged In: YES user_id=569123 I've been meaning to upgrade from 3.0.0. Looks like soon I'll have to do so and verify. Thanks. -- Comment By: Gerald Turner (crazyfoam) Date: 2003-02-11 20:58 Message: Logged In: YES user_id=571620 Looks like this is fixed in 3.0.7RC1! -- Comment By: Gerald Turner (crazyfoam) Date: 2003-02-11 15:10 Message: Logged In: YES user_id=571620 http://unzane.com/sf-bug-575966.txt Hmph! I can't attach a file (because I'm not reporter or admin?). So here's a URL... http://unzane.com/sf-bug-575966.txt";>attachment -- Comment By: Gerald Turner (crazyfoam) Date: 2003-02-11 15:06 Message: Logged In: YES user_id=571620 I have also ran into this bug while enabling deferred contraints in an Oracle database. JBoss 3.0.4 through 3.0.6, Java 1.4.1_01 on Solaris and Linux. Oracle 9.2.0.1 using thin driver and non-xa datasource. I will attach a concise log of transaction behavior when a deferred constraint is violated at commit (in which TxCapsule ignores it!), and also a log of the behavior of when the deferred constraint is replaced with an immediate constraint thus behaving normally (throws CreateException). FYI, I noticed this email on jboss-user which explains the same situation: http://www.mail-archive.com/jboss-user@lists.sourceforge.net/msg23139.html -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=575966&group_id=22866 --- 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-dev] [ jboss-Bugs-575966 ] JCA - commit failure not reported
Bugs item #575966, was opened at 2002-07-01 13:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=575966&group_id=22866 Category: JBossTX Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Paul Adams (padams) Assigned to: David Jencks (d_jencks) Summary: JCA - commit failure not reported Initial Comment: JBoss: 3.0 integrated with tomcat JDK: 1.4.0 OS: Win2K Connector deployed with LocalTransaction support. Failure to commit a transaction is not reported to the client. Logged stack trace below: 08:52:28,927 WARN [TxCapsule] XAException: tx=XidImpl [FormatId=257, GlobalId=padams//0, BranchQual=] errorCode=XA_UNKNOWN(0) javax.transaction.xa.XAException: could not commit local txjavax.resource.ResourceExceptio n: Server.InternalServerError:failure to commit at org.jboss.resource.connectionmanager.LocalTxConnectionManager$LocalConnectionEv entListener.commit(LocalTxConnectionManager.java:563) at org.jboss.tm.TxCapsule.commitResources(TxCapsule.java:1656) at org.jboss.tm.TxCapsule.commit(TxCapsule.java:357) at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:74) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.jav a:190) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:61) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:166) at org.jboss.ejb.StatefulSessionContainer.invoke(StatefulSessionContainer.java:380 ) at org.jboss.ejb.Container.invoke(Container.java:705) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491) at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:362) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.ja va:25) at java.lang.reflect.Method.invoke(Method.java:324) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261) at sun.rmi.transport.Transport$1.run(Transport.java:148) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:144) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701) at java.lang.Thread.run(Thread.java:536) -- Comment By: Marcel (speck99) Date: 2003-02-12 15:18 Message: Logged In: YES user_id=657615 Hi, I once committed a patch patch tracker id 644604) for this: https://sourceforge.net/tracker/index.php?func=detail&aid=644604&group_id=22866&atid=376687 As far as I know this patch for 3.0.4 works also for version 3.0.6. I just reattached an updated patch, this time against version 3.0.5 and including an improved log statement (so that you can actually see which deferred constraint was the cause of the commit fail). I'm happy about any feedback :-) CU, Marcel -- Comment By: Paul Adams (padams) Date: 2003-02-12 15:02 Message: Logged In: YES user_id=569123 I've been meaning to upgrade from 3.0.0. Looks like soon I'll have to do so and verify. Thanks. -- Comment By: Gerald Turner (crazyfoam) Date: 2003-02-12 02:58 Message: Logged In: YES user_id=571620 Looks like this is fixed in 3.0.7RC1! -- Comment By: Gerald Turner (crazyfoam) Date: 2003-02-11 21:10 Message: Logged In: YES user_id=571620 http://unzane.com/sf-bug-575966.txt Hmph! I can't attach a file (because I'm not reporter or admin?). So here's a URL... http://unzane.com/sf-bug-575966.txt";>attachment -- Comment By: Gerald Turner (crazyfoam) Date: 2003-02-11 21:06 Message: Logged In: YES user_id=571620 I have also ran into this bug while enabling deferred contraints in an Oracle database. JBoss 3.0.4 through 3.0.6, Java 1.4.1_01 on Solaris and Linux. Oracle 9.2.0.1 using thin driver and non-xa datasource. I will attach a concise log of transaction behavior when a deferred constraint is violated at commit (in which TxCapsule ignores it!), and also a log of the behavior of when the deferred constraint is replaced with an immediate constraint thus behaving normally (throws CreateException). FYI, I noticed this email on jboss-user which explains the same situation: http://www.mail-archive.com/jboss-user@lists.sourceforge.net/msg23139.html -- You can respond by visitin
Re: [JBoss-dev] Remote class loading servlet
On further testing the ExportException went away but I'd still like to know how to plugin the servlet. James James Cooley wrote: Hi Dain, Scott, I wrote a servlet that accepts a request from a java.net.URLClassLoader and returns the class. AFAIK I need only support requests of the kind org/jboss/util/stream/Streams.class but the exising WebServer class also supports "SomeClassName[some/object/id]/some/file/path" I can't find where this protocol is defined elsewhere - please point me at the spec if we need to support it - I'm a bit blind as to what we need as you can see from the next question ... I created a class-loader.war and I tried running the JRMP tests with ./testsuite/build.sh -Djava.rmi.server.codebase=http://localhost:8080/class-loader/ -Dtest=jrmp test but it doesn't work and I get ERROR [JRMPInvoker] Starting failed: java.rmi.server.ExportException: Port already in use: 4447; What am I doing wrong? How can I test this. 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 --- 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 --- 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
Re: [JBoss-dev] Remote class loading servlet
You won't find this in the servlet spec. "SomeClassName[some/object/id]/some/file/path" is a JBoss convention for specifying Java classes and resources dynamically downloaded by clients. It is used by org.jboss.web.WebClassLoader and by org.jboss.iiop.WebCL. See comments in server/src/main/org/jboss/web/WebServer.java See also server/src/main/org/jboss/web/WebClassLoader.java iiop/src/main/org/jboss/iiop/WebCL.java Cheers, Francisco On Wed, 12 Feb 2003, James Cooley wrote: > Hi Dain, Scott, > > I wrote a servlet that accepts a request from a java.net.URLClassLoader > and returns the class. AFAIK I need only support requests of the kind > org/jboss/util/stream/Streams.class > but the exising WebServer class also supports > > "SomeClassName[some/object/id]/some/file/path" > > I can't find where this protocol is defined elsewhere - please point me > at the spec if we need to support it - I'm a bit blind as to what we > need as you can see from the next question ... > > I created a class-loader.war and I tried running the JRMP tests with > > ./testsuite/build.sh > -Djava.rmi.server.codebase=http://localhost:8080/class-loader/ > -Dtest=jrmp test > > but it doesn't work and I get > > ERROR [JRMPInvoker] Starting failed: java.rmi.server.ExportException: > Port already in use: 4447; > > What am I doing wrong? How can I test this. > > 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 > > > > > > > > > --- > 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 > --- 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-dev] [ jboss-Bugs-620838 ] jboss-3.0.3 Crashes with jdk1.4.1
Bugs item #620838, was opened at 2002-10-09 15:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=620838&group_id=22866 Category: None Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Jay Petersen (s2jcpete) Assigned to: Scott M Stark (starksm) Summary: jboss-3.0.3 Crashes with jdk1.4.1 Initial Comment: OS=Conectiva Linux 8 JDK=1.4.1-fcs Version=jboss-3.0.3 (md5sum = 342c4c636ff96b01aa1e13188ca16a63 jboss-3.0.3.zip). When executing the run.sh file, it would crash saying null pointer exception when instantiating org.jboss.web.WebService. Switched to jdk1.4.0_02 and everything runs fine. ERROR [Server] start failed org.jboss.deployment.DeploymentException: org.jboss.web.WebService constructor has thrown an exception: java.lang.NullPointerException; - nested throwable: (RuntimeMBeanException: org.jboss.web.WebService constructor has thrown an exception: java.lang.NullPointerException Cause: java.lang.NullPointerException) at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java:155) at org.jboss.system.ServiceController.install(ServiceController.java:225) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) at $Proxy3.install(Unknown Source) at org.jboss.deployment.SARDeployer.create(SARDeployer.java:209) at org.jboss.deployment.MainDeployer.create(MainDeployer.java:755) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:615) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:580) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:564) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:324) at org.jboss.system.server.ServerImpl.start(ServerImpl.java:221) at org.jboss.Main.boot(Main.java:148) at org.jboss.Main$1.run(Main.java:381) at java.lang.Thread.run(Thread.java:536) Caused by: RuntimeMBeanException: org.jboss.web.WebService constructor has thrown an exception: java.lang.NullPointerException Cause: java.lang.NullPointerException at org.jboss.mx.server.MBeanServerImpl.handleInstantiateExceptions(MBeanServerImpl.java:854) at org.jboss.mx.server.MBeanServerImpl.instantiate(MBeanServerImpl.java:816) at org.jboss.mx.server.MBeanServerImpl.instantiate(MBeanServerImpl.java:266) at org.jboss.mx.server.MBeanServerImpl.createMBean(MBeanServerImpl.java:293) at org.jboss.system.ServiceCreator.install(ServiceCreator.java:86) at org.jboss.system.ServiceConfigurator.internalInstall(ServiceConfigurator.java:167) at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java:130) ... 25 more -- Comment By: Thomas Campbell (dimlark) Date: 2003-02-12 18:22 Message: Logged In: YES user_id=710830 We just formatted a RH8.0 box, installed the JDK1.4.1 and jBoss-3.0.4 then 3.0.3 because we were having the same problem. However, we couldn't bring up Apache, either. We had changed hostname, but its not registered with our internal DNS. Changed it back to 'localhost' and everything worked. Tested this by changing and returning the hostname to localhost 5 times each. Localhost always works. Others do not. Both jboss- 3.0.3 and jboss-3.0.4 start fine now. Hope this helps. -- Comment By: Steven Ostrowski (alchemista) Date: 2003-01-23 03:38 Message: Logged In: YES user_id=552047 OK, the source code lines are in the exceptions of the stack trace I posted, so I'm not sure what other lines you are referring to. Since I don't know, I guess I will have to wait until the next release. -- Comme
[JBoss-dev] [ jboss-Bugs-684605 ] Two connections in one XA transaction
Bugs item #684605, was opened at 2003-02-11 14:37
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=684605&group_id=22866
Category: JBossTX
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Marek Drejak (marekdrejak)
>Assigned to: David Jencks (d_jencks)
Summary: Two connections in one XA transaction
Initial Comment:
I am testing JBoss 3.2.0RC1 and Oracle 9.0.1.2.0 on
Windows 2000 using JDK 1.4.0_02.
I have deployed a "thin" OracleXADataSource without
default username and password, setting
ManagedConnectionPool's Criteria to ByApplication.
In runtime, during one transaction, I call first
ds.getConnection("user1",password1") and then
ds.getConnection("user2",password2"), which gives error
message "Wrong credentials passed to getConnection!".
Is it not allowed to have two different connections from
one data source during one XA transaction?
Or is it a bug?
I deployed the data source using oracle-xa-service.xml
(from docs\examples\jca). I tried also deployment with
oracle-xa-ds.xml with the same result.
I attach a file with trace from the console.
--
>Comment By: David Jencks (d_jencks)
Date: 2003-02-12 18:47
Message:
Logged In: YES
user_id=60525
I'll have to think about whether this can be supported. Meanwhile can you use more
than one datasource, two in your example?
--
Comment By: Marek Drejak (marekdrejak)
Date: 2003-02-11 14:52
Message:
Logged In: YES
user_id=709725
Here comes the file with trace from the console
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=684605&group_id=22866
---
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
[JBoss-dev] [ jboss-Bugs-682618 ] xDoclet: xmbean generation does not match the DTD
Bugs item #682618, was opened at 2003-02-07 22:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=682618&group_id=22866 Category: None Group: v4.0 Status: Open Resolution: None Priority: 7 Submitted By: Matthew Munz (mattmunz) >Assigned to: David Jencks (d_jencks) Summary: xDoclet: xmbean generation does not match the DTD Initial Comment: I wasn't sure where to submit this-- if this is the wrong place, let me know... The XMBean XML generated by xDoclet does not fit the XMBean DTD. Essentially, the descriptors are written in the wrong order. Here are my xDoclet tags * @jmx.mbean * persistPolicy = "OnUpdate" * persistName = "Resource2-state.xml" * persistLocation = "D:/Matt/apelon/temporary/MBean-Repository" * display-name = "Resource #2 Test MBean" * name = "jboss.jmx.test:name=Resource2" * persistence-manager = "org.jboss.mx.persistence.XMLPersistenceManager" * @jboss.xmbean here's the xml generated by xDoclet and here's the parser error org.xml.sax.SAXParseException: The content of element type "descriptors" must match (persistence?,currencyTimeLimit?,state-action-on-update?,display-name?, default?,value?,persistence-manager?,descriptor*)". - Matt -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=682618&group_id=22866 --- 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
[JBoss-dev] [ jboss-Bugs-682511 ] Client receives RemoteException instead of TransRolledBackEx
Bugs item #682511, was opened at 2003-02-07 19:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=682511&group_id=22866 Category: JBossTX Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Bob Cotton (bcotton969) >Assigned to: David Jencks (d_jencks) Summary: Client receives RemoteException instead of TransRolledBackEx Initial Comment: This is Jboss 3_2RC1 >From an EJB, we are doing 2-phase commits. One with Oracle XA and one with Gemstone's JCA Adapter. Gemstone votes rollback, and the client recieves a RemoteException with a nested TransactionRolledBackExcpetion. I was expecting the client to receive the TransactionRolledBackException directly. Here are the stack traces. Stack From Gemstone: 2003-02-07 18:55:55,898 WARN [org.jboss.tm.TransactionImpl] XAException: tx=TransactionImpl:XidImpl [Format Id=257, GlobalId=malt//739691, BranchQual=] errorCode=XA_RBROLLBACK javax.transaction.xa.XAException at com.gemstone.persistence.connection.internal.ContainerXAResource.prepare(ContainerXAResource.java :343) at org.jboss.tm.TransactionImpl.prepareResources(TransactionImpl.java:1340) at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:355) at org.jboss.ejb.plugins.TxInterceptorCMT.endTransaction(TxInterceptorCMT.java:361) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:247) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:101) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:204) at org.jboss.ejb.plugins.CleanShutdownInterceptor.invoke(CleanShutdownInterceptor.java:265) at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:154 ) at org.jboss.ejb.StatefulSessionContainer.invoke(StatefulSessionContainer.java:370) at org.jboss.ejb.Container.invoke(Container.java:680) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.invocation.jrmp.server.JRMPInvokerHA.invoke(JRMPInvokerHA.java:163) at java.lang.reflect.Method.invoke(Native Method) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:236) at sun.rmi.transport.Transport$1.run(Transport.java:147) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:143) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701) at java.lang.Thread.run(Thread.java:479) Stack From JBoss: 2003-02-07 18:55:55,953 ERROR [org.jboss.ejb.plugins.LogInterceptor] TransactionRolledbackException: javax.transaction.TransactionRolledbackException: Unable to commit, tx=TransactionImpl:XidImpl [FormatId=257 , GlobalId=malt//739691, BranchQual=] status=STATUS_NO_TRANSACTION at org.jboss.ejb.plugins.TxInterceptorCMT.endTransaction(TxInterceptorCMT.java:368) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:247) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:101) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:204) at org.jboss.ejb.plugins.CleanShutdownInterceptor.invoke(CleanShutdownInterceptor.java:265) at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:154 ) at org.jboss.ejb.StatefulSessionContainer.invoke(StatefulSessionContainer.java:370) at org.jboss.ejb.Container.invoke(Container.java:680) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.invocation.jrmp.server.JRMPInvokerHA.invoke(JRMPInvokerHA.java:163) at java.lang.reflect.Method.invoke(Native Method) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:236) at sun.rmi.transport.Transport$1.run(Transport.java:147) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:143) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701) at java.lang.Thread.run(Thread.java:479) Stack From Client: [java] EJBREMOTEMANAGER RemoteException occured in com.synxis.wizdom.ejbs.SrmsWizcomMsgProcessorRemoteIF: attempt #0 [java] java.rmi.ServerException: RemoteException occurred in server thread; nested exception is: [java] RemoteException: RemoteException occurred in server thread; nested exception is: [java] javax.transaction.TransactionRolledbackException: Unable to commit, tx=TransactionImpl:XidImpl [FormatId=257, GlobalId=malt//735599, BranchQual=] status=STATUS_NO_TRANSACTION [jav
[JBoss-dev] [ jboss-Bugs-680956 ] TxCapsule.doBeforeCompletion: exception swallowed
Bugs item #680956, was opened at 2003-02-05 15:04
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=680956&group_id=22866
Category: JBossTX
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Jakob Spies (jspies)
>Assigned to: David Jencks (d_jencks)
Summary: TxCapsule.doBeforeCompletion: exception swallowed
Initial Comment:
OS: Mac OS X 10.2.3
JDK 1.3.1
The method org.jboss.tm.TxCapsule.doBeforeCompletion in
JBoss 3.0.4 contains the following code:
try
{
if (trace)
{
log.trace("calling sync " + i + ", "
+ sync[i]);
} // end of if ()
sync[i].beforeCompletion();
} catch (Throwable t)
{
if (trace)
{
log.trace("failed before completion", t);
}
status = Status.STATUS_MARKED_ROLLBACK;
break;
}
}
This means that if sync[i].beforeCompletion() throws an
exception and trace == false, the exception with all
its error information is thrown into the bit bucket. I
consider this a bug.
(In my case e.g., sync[i] represents a JCA resource
adapter for JDO, and I would not have been able to find
the cause (a database issue) for a transaction rollback
without debugging into JBoss.)
--
>Comment By: David Jencks (d_jencks)
Date: 2003-02-12 18:53
Message:
Logged In: YES
user_id=60525
Dain just fixed this in 3.0. One of us will be porting the fix to 3.2 and 4 shortly.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=680956&group_id=22866
---
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
[JBoss-dev] [ jboss-Bugs-673371 ] NoTxConnection named LocalTx...
Bugs item #673371, was opened at 2003-01-23 21:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=673371&group_id=22866 Category: JBossServer Group: CVS HEAD Status: Open Resolution: None Priority: 5 Submitted By: Frank Langelage (lafr) >Assigned to: David Jencks (d_jencks) Summary: NoTxConnection named LocalTx... Initial Comment: I deployed a jca-adapter and a mbi3-ds.xml file with the following content: eis/MBI3 MBI3 rm200 1408 0 1 360 The result is a ConnectionManager with a wrong name: [jca.mbi3.ManagedConnectionFactoryImpl.eis/MBI3.info] Bound connection factory for resource adapter for ConnectionManager 'jboss.jca:service=LocalTxCM,name=eis/MBI3 to JNDI name 'java:/eis/MBI3' LocalTx instead of NoTx ! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=673371&group_id=22866 --- 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
[JBoss-dev] [ jboss-Bugs-685329 ] Java-Editor in Eclipse M5 does not work when JBoss-IDE inst.
Bugs item #685329, was opened at 2003-02-12 14:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=685329&group_id=22866 Category: JBoss-IDE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dr. Domagoj Cosic (domic) Assigned to: Nobody/Anonymous (nobody) Summary: Java-Editor in Eclipse M5 does not work when JBoss-IDE inst. Initial Comment: I installed jbosside1.0a_06.zip over M5 eclipse. From now on the Java Editor did not work. Already open editor windows showed a red "An error has occured when creating this editor" and an attempt to open a new one led to the error alert box "Unable to create part: foo.java". Uninstalling the plugin removed that problem too but from now on the editor font was reset to the default system font and the preferences for Java Editor Font under Workbench/Fonts/ (not Java/Editor any more in M5) to set the font size was missing. Re-installing M5 in the same directory (preserving the other plugins) solved the problem. -- Comment By: Markus Kling (mkling) Date: 2003-02-12 19:10 Message: Logged In: YES user_id=360804 The JBoss plugin modifies the plugin.xml of the org.eclipse.jdt.ui.* imho to add the jbossjar to the classpath. Restore your old plugin.xml, or diff the new against the original version and make the changes manually. Eclipse should work then. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=685329&group_id=22866 --- 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
[JBoss-dev] [ jboss-Bugs-685473 ] JBoss 3.0.6 startup error with Compaq Java 1.4
Bugs item #685473, was opened at 2003-02-12 14:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=685473&group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: John Stalker (jstalker) Assigned to: Nobody/Anonymous (nobody) Summary: JBoss 3.0.6 startup error with Compaq Java 1.4 Initial Comment: OS: OSF1 iridium V5.1 1885 alpha alpha JDK: Java VM: Fast VM 1.4.0-1,Compaq Computer Corp. JBoss version: 3.0.6 I downloaded the source files from cvs using the JBoss_3_0_6 tag and compiled it (went fine) using the aforementioned JDK1.4.0 from Compaq. The resulting startup output is identical to the JBoss 3.0.5 output. As an aside, the 3.0.4 works just fine! Thanks again, John OUTPUT: JBoss Bootstrap Environment JBOSS_HOME: /home/iridium/prodinfo/tools/jboss JAVA: /usr/opt/java140/bin/java JAVA_OPTS: -DSQENV=jstalker -Dprogram.name=run.sh CLASSPATH: /home/iridium/prodinfo/tools/jboss/bin/run.jar:/usr/opt/java140/lib/tools.jar run.sh: unused non-option argument: 13:14:39,015 INFO [Server] JBoss Release: JBoss-3.0.6 CVSTag=JBoss_3_0_6 13:14:39,050 INFO [Server] Home Dir: /usr/home/prodinfo/tools/jboss-3.0.6 13:14:39,053 INFO [Server] Home URL: file:/usr/home/prodinfo/tools/jboss-3.0.6/ 13:14:39,058 INFO [Server] Library URL: file:/usr/home/prodinfo/tools/jboss-3.0.6/lib/ 13:14:39,070 INFO [Server] Patch URL: null 13:14:39,071 INFO [Server] Server Name: jstalker 13:14:39,072 INFO [Server] Server Home Dir: /usr/home/prodinfo/tools/jboss-3.0.6/server/jstalker 13:14:39,076 INFO [Server] Server Home URL: file:/usr/home/prodinfo/tools/jboss-3.0.6/server/jstalker/ 13:14:39,078 INFO [Server] Server Data Dir: /usr/home/prodinfo/tools/jboss-3.0.6/server/jstalker/db 13:14:39,079 INFO [Server] Server Temp Dir: /usr/home/prodinfo/tools/jboss-3.0.6/server/jstalker/tmp 13:14:39,081 INFO [Server] Server Config URL: file:/usr/home/prodinfo/tools/jboss-3.0.6/server/jstalker/conf/ 13:14:39,082 INFO [Server] Server Library URL: file:/usr/home/prodinfo/tools/jboss-3.0.6/server/jstalker/lib/ 13:14:39,082 INFO [Server] Root Deployemnt Filename: jboss-service.xml 13:14:39,090 INFO [Server] Starting General Purpose Architecture (GPA)... 13:14:39,652 INFO [ServerInfo] Java version: 1.4.0,Compaq Computer Corp. 13:14:39,652 INFO [ServerInfo] Java VM: Fast VM 1.4.0-1,Compaq Computer Corp. 13:14:39,652 INFO [ServerInfo] OS-System: OSF1 V5.1,alpha 13:14:39,721 INFO [ServiceController] Controller MBean online 13:14:39,931 INFO [MainDeployer] Creating 13:14:39,993 INFO [MainDeployer] Created 13:14:39,999 INFO [MainDeployer] Starting 13:14:40,002 INFO [MainDeployer] Started 13:14:40,027 INFO [JARDeployer] Creating 13:14:40,027 INFO [JARDeployer] Created 13:14:40,032 INFO [JARDeployer] Starting 13:14:40,034 INFO [MainDeployer] Adding deployer: org.jboss.deployment.JARDeployer@80a3884 13:14:40,035 INFO [JARDeployer] Started 13:14:40,063 INFO [SARDeployer] Creating 13:14:40,063 INFO [SARDeployer] Created 13:14:40,064 INFO [SARDeployer] Starting 13:14:40,064 INFO [MainDeployer] Adding deployer: org.jboss.deployment.SARDeployer@80a7aac 13:14:40,100 INFO [SARDeployer] Started 13:14:40,100 INFO [Server] Core system initialized 13:14:40,107 INFO [MainDeployer] Starting deployment of package: file:/usr/home/prodinfo/tools/jboss-3.0.6/server/jstalker/conf/jboss-service.xml Java stack overflow in make_native_call for method run 13:14:41,964 ERROR [MainDeployer] could not create deployment: file:/usr/home/prodinfo/tools/jboss-3.0.6/server/jstalker/conf/jboss-service.xml org.jboss.deployment.DeploymentException: instantiating org.jboss.varia.property.PropertyEditorManagerService failed: java.lang.StackOverflowError; - nested throwable: (RuntimeErrorException: instantiating org.jboss.varia.property.PropertyEditorManagerService failed: java.lang.StackOverflowError Cause: java.lang.StackOverflowError) at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java:153) at org.jboss.system.ServiceController.install(ServiceController.java:231) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) at $Proxy2.install(Unknown Source) at org.jboss.deployment.SARDeployer.create(SARDeployer.java:189) a
Re: [JBoss-dev] Remote class loading servlet
Drop it in the deploy directory like everything else and add the java.rmi.server.codebase=http://localhost:8080/class-loader/ system property in the server. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "James Cooley" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, February 12, 2003 8:58 AM Subject: Re: [JBoss-dev] Remote class loading servlet > On further testing the ExportException went away but I'd still like to > know how to plugin the servlet. > > James > > James Cooley wrote: > > Hi Dain, Scott, > > > > I wrote a servlet that accepts a request from a java.net.URLClassLoader > > and returns the class. AFAIK I need only support requests of the kind > > org/jboss/util/stream/Streams.class > > but the exising WebServer class also supports > > > > "SomeClassName[some/object/id]/some/file/path" > > > > I can't find where this protocol is defined elsewhere - please point me > > at the spec if we need to support it - I'm a bit blind as to what we > > need as you can see from the next question ... > > > > I created a class-loader.war and I tried running the JRMP tests with > > > > ./testsuite/build.sh > > -Djava.rmi.server.codebase=http://localhost:8080/class-loader/ > > -Dtest=jrmp test > > > > but it doesn't work and I get > > > > ERROR [JRMPInvoker] Starting failed: java.rmi.server.ExportException: > > Port already in use: 4447; > > > > What am I doing wrong? How can I test this. > > > > 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 > >> > >> > > > > > > > > > > --- > > 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 > > > > > > > > > --- > 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 > --- 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
[JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 12-February-2003
JBoss daily test results SUMMARY Number of tests run: 1026 Successful tests: 1023 Errors:2 Failures: 1 [time of test: 2003-02-12.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.3] See http://users.jboss.org/~starksm/Branch_3_0/2003-02-12.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: LocalWrapperCleanupUnitTestCase Test: testAutoCommitOffInRemoteUserTx(org.jboss.test.jca.test.LocalWrapperCleanupUnitTestCase) Type:error Exception: java.rmi.ServerException Message: RemoteException occurred in server thread; nested exception is: java.rmi.ServerException: EJBException:; nested exception is: javax.ejb.EJBException: Row committed, autocommit still on! - 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: BeanStressTestCase Test:testDeadLockFromClient(org.jboss.test.deadlock.test.BeanStressTestCase) Type:failure Exception: junit.framework.AssertionFailedError Message: expected a client deadlock for AB BA - --- 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
[JBoss-dev] Automated JBoss(Branch_3_2 WonderLand) Testsuite Results: 12-February-2003
JBoss daily test results SUMMARY Number of tests run: 1074 Successful tests: 1065 Errors:7 Failures: 2 [time of test: 2003-02-12.20-40 GMT] [java.version: 1.4.1_01] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.4.1_01-b01] [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-12.20-40 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: 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:/usr/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: JarInSarJSR77UnitTestCase Test: testFakeParentCreatedAndRemoved(org.jboss.test.jmx.test.JarInSarJSR77UnitTestCase) Type:failure Exception: junit.framework.AssertionFailedError Message: fakeApp jsr-77 mbean is still present - 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:/usr/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: java.lang.NullPointerException Message: - Suite: BeanStressTestCase Test:testOldProxy(org.jboss.test.pooled.test.BeanStressTestCase) Type:error Exception: java.lang.reflect.UndeclaredThrowableException Message: - Suite: HttpsUnitTestCase Test:testJSSE(org.jboss.test.security.test.HttpsUnitTestCase) Type:error Exception: java.net.BindException Message: Address already in use: JVM_Bind - Suite: SRPUnitTestCase Test:testEchoArgs(org.jboss.test.security.test.SRPUnitTestCase) Type:error Exception: java.lang.reflect.UndeclaredThrowableException Message: - Suite: WebIntegrationUnitTestCase Test:testJSPClasspath(org.jboss.test.web.test.WebIntegrationUnitTestCase) Type:failure Exception: junit.framework.AssertionFailedError Message: Access to: http://jduke:theduke@localhost:8080/jbosstest/classpath.jsp failed with responseCode=500 - --- 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
[JBoss-dev] TxInterceptor split is bad
What if you don't have java on the client side? What if you're CORBA with OTS? You're making it harder for Non-JBoss/Java clients to integrated with us. I think this split should be undone. BTW, why the split besides code readability? Is the DTM dependent on this at all? Is the TM even accessed on the client side? Another problem I see is that the TxMethod map is required on the client side as well. Makes proxies even more heavy and what do you do about a hot deploy? Seems to me this is a bad idea. Bill --- 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
Re: [JBoss-dev] TxInterceptor split is bad
--- Bill Burke <[EMAIL PROTECTED]> wrote: > What if you don't have java on the client side? > What if you're CORBA with > OTS? You're making it harder for Non-JBoss/Java > clients to integrated with > us. I think this split should be undone. > How des OTS work? The corba guys tackled the DTM problem too right?? > BTW, why the split besides code readability? Is the > DTM dependent on this > at all? Is the TM even accessed on the client side? > I think so. In the case were a client is a server the local TM is accessed to treat the remote TM like a XAResource. > Another problem I see is that the TxMethod map is > required on the client > side as well. Makes proxies even more heavy and > what do you do about a hot > deploy? > Yes.. but same argument could be made against any client side interceptor we create. The proxy on the client goes stale if a redeploy changes the proxy config. > Seems to me this is a bad idea. > I agree it is a complex solution. But the DTM problem is complex too. Any simpler sugestions?? Regards, Hiram > Bill > > > > --- > 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 __ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com --- 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
[JBoss-dev] HttpProxyServlet?
I'm currently working with a client who uses IIS/ServletExec due to legacy issues. IIS is bound to port 80 and 443 on the PC's one IP. The firewall is only open on port 80 and 443 for the machine's one IP. Some requests need to be serviced by IIS/ServletExec, while others need to be serviced by Web/JBoss (Jetty). Therefore, we need to set up IIS/ServletExec to act as a proxy to Web/JBoss running on the same machine on port 8080, taking requests on port 80 or 443, reissuing them Web/JBoss (Jetty) on port 8080 and returning the response to the client. I.E. HttpProxyServlet? I started writing one for my very specific use case, but figured it may be a more useful addition if it were more generalized and could handle *any* HTTP or HTTPS requests. Has anyone got something like this? Thanks, Nathan --- 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
RE: [JBoss-dev] TxInterceptor split is bad
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Hiram > Chirino > Sent: Wednesday, February 12, 2003 5:09 PM > To: [EMAIL PROTECTED]; David Jencks > Subject: Re: [JBoss-dev] TxInterceptor split is bad > > > --- Bill Burke <[EMAIL PROTECTED]> wrote: > > What if you don't have java on the client side? > > What if you're CORBA with > > OTS? You're making it harder for Non-JBoss/Java > > clients to integrated with > > us. I think this split should be undone. > > > > How des OTS work? The corba guys tackled the DTM > problem too right?? > They have the concept of a ThreadLocal (Current) (My knowledge is probably outdated and foggy). In O2K the client side interceptor stuffs the value from the transaction current into the IIOP service context, much the same way we used to do before David's switch. -1 for refactor > > BTW, why the split besides code readability? Is the > > DTM dependent on this > > at all? Is the TM even accessed on the client side? > > > > I think so. In the case were a client is a server the > local TM is accessed to treat the remote TM like a > XAResource. > +1 for refactor > > Another problem I see is that the TxMethod map is > > required on the client > > side as well. Makes proxies even more heavy and > > what do you do about a hot > > deploy? > > > > Yes.. but same argument could be made against any > client side interceptor we create. The proxy on the > client goes stale if a redeploy changes the proxy > config. > Ok, you're right. +2 for refactor > > Seems to me this is a bad idea. > > > > I agree it is a complex solution. But the DTM problem > is complex too. Any simpler sugestions?? > Actually the code is much more readable. I guess my only concern now is non-java/jboss clients. And, do we care? Another thing about this is that you're requiring the client to become beafier and beafier. I've been kinda nervous about the whole JMX on the client sort of thing and the start of deploying services on the client side. But maybe it doesn't matter. Bill P.S. Good to see you around again Hiram. --- 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
RE: [JBoss-dev] TxInterceptor split is bad
Another thing David, I don't see you always stuffing the Transaction into the invocation object. A few interceptors rely on the transaction being in the invocation object. Any objects to fixing this? Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Bill > Burke > Sent: Wednesday, February 12, 2003 5:36 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] TxInterceptor split is bad > > > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of Hiram > > Chirino > > Sent: Wednesday, February 12, 2003 5:09 PM > > To: [EMAIL PROTECTED]; David Jencks > > Subject: Re: [JBoss-dev] TxInterceptor split is bad > > > > > > --- Bill Burke <[EMAIL PROTECTED]> wrote: > > > What if you don't have java on the client side? > > > What if you're CORBA with > > > OTS? You're making it harder for Non-JBoss/Java > > > clients to integrated with > > > us. I think this split should be undone. > > > > > > > How des OTS work? The corba guys tackled the DTM > > problem too right?? > > > > They have the concept of a ThreadLocal (Current) (My knowledge > is probably > outdated and foggy). In O2K the client side interceptor stuffs the value > from the transaction current into the IIOP service context, much the same > way we used to do before David's switch. > > -1 for refactor > > > > BTW, why the split besides code readability? Is the > > > DTM dependent on this > > > at all? Is the TM even accessed on the client side? > > > > > > > I think so. In the case were a client is a server the > > local TM is accessed to treat the remote TM like a > > XAResource. > > > > +1 for refactor > > > > Another problem I see is that the TxMethod map is > > > required on the client > > > side as well. Makes proxies even more heavy and > > > what do you do about a hot > > > deploy? > > > > > > > Yes.. but same argument could be made against any > > client side interceptor we create. The proxy on the > > client goes stale if a redeploy changes the proxy > > config. > > > > Ok, you're right. +2 for refactor > > > > Seems to me this is a bad idea. > > > > > > > I agree it is a complex solution. But the DTM problem > > is complex too. Any simpler sugestions?? > > > > Actually the code is much more readable. I guess my only concern now is > non-java/jboss clients. And, do we care? > > Another thing about this is that you're requiring the client to become > beafier and beafier. I've been kinda nervous about the whole JMX on the > client sort of thing and the start of deploying services on the > client side. > But maybe it doesn't matter. > > Bill > > P.S. Good to see you around again Hiram. > > > > --- > 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
Re: [JBoss-dev] TxInterceptor split is bad
> Another problem I see is that the TxMethod map is required on the client > side as well. Makes proxies even more heavy and what do you do about a hot > deploy? The hot deploy is a general issue with proxies. Whether or not this works depends on the transport endpoint. RMI/JRMP proxies do not work across a hot deploy, and most p2p transports do not. Making the proxies more robust across hot deploys using our own transports, etc. is something we should work towards. A java.lang.reflect.Method map is a very anti-hot-deploy construct because of the strong typing of the Method to its class. We should certainly look to limit the exposure of such a mapping outside of the VM. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Bill Burke" <[EMAIL PROTECTED]> To: "David Jencks" <[EMAIL PROTECTED]>; "Jboss-Dev" <[EMAIL PROTECTED]> Sent: Wednesday, February 12, 2003 1:31 PM Subject: [JBoss-dev] TxInterceptor split is bad > What if you don't have java on the client side? What if you're CORBA with > OTS? You're making it harder for Non-JBoss/Java clients to integrated with > us. I think this split should be undone. > > BTW, why the split besides code readability? Is the DTM dependent on this > at all? Is the TM even accessed on the client side? > --- 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
RE: [JBoss-dev] TxInterceptor split is bad AND broken?
Ok, I'm looking at the code further and I'm pretty confused on how a Transaction get propagated across the wire now. Can you explain? I don't see any code anywhere that is doing a tm.resume from the transaction that is past across the wire. Is this code broken? Bill > -Original Message- > From: Bill Burke [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, February 12, 2003 5:51 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] TxInterceptor split is bad > > > Another thing David, > > I don't see you always stuffing the Transaction into the > invocation object. A few interceptors rely on the transaction > being in the invocation object. Any objects to fixing this? > > Bill > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of Bill > > Burke > > Sent: Wednesday, February 12, 2003 5:36 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] TxInterceptor split is bad > > > > > > > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED]]On > Behalf Of Hiram > > > Chirino > > > Sent: Wednesday, February 12, 2003 5:09 PM > > > To: [EMAIL PROTECTED]; David Jencks > > > Subject: Re: [JBoss-dev] TxInterceptor split is bad > > > > > > > > > --- Bill Burke <[EMAIL PROTECTED]> wrote: > > > > What if you don't have java on the client side? > > > > What if you're CORBA with > > > > OTS? You're making it harder for Non-JBoss/Java > > > > clients to integrated with > > > > us. I think this split should be undone. > > > > > > > > > > How des OTS work? The corba guys tackled the DTM > > > problem too right?? > > > > > > > They have the concept of a ThreadLocal (Current) (My knowledge > > is probably > > outdated and foggy). In O2K the client side interceptor stuffs > the value > > from the transaction current into the IIOP service context, > much the same > > way we used to do before David's switch. > > > > -1 for refactor > > > > > > BTW, why the split besides code readability? Is the > > > > DTM dependent on this > > > > at all? Is the TM even accessed on the client side? > > > > > > > > > > I think so. In the case were a client is a server the > > > local TM is accessed to treat the remote TM like a > > > XAResource. > > > > > > > +1 for refactor > > > > > > Another problem I see is that the TxMethod map is > > > > required on the client > > > > side as well. Makes proxies even more heavy and > > > > what do you do about a hot > > > > deploy? > > > > > > > > > > Yes.. but same argument could be made against any > > > client side interceptor we create. The proxy on the > > > client goes stale if a redeploy changes the proxy > > > config. > > > > > > > Ok, you're right. +2 for refactor > > > > > > Seems to me this is a bad idea. > > > > > > > > > > I agree it is a complex solution. But the DTM problem > > > is complex too. Any simpler sugestions?? > > > > > > > Actually the code is much more readable. I guess my only concern now is > > non-java/jboss clients. And, do we care? > > > > Another thing about this is that you're requiring the client to become > > beafier and beafier. I've been kinda nervous about the whole JMX on the > > client sort of thing and the start of deploying services on the > > client side. > > But maybe it doesn't matter. > > > > Bill > > > > P.S. Good to see you around again Hiram. > > > > > > > > --- > > 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
Re: [JBoss-dev] HttpProxyServlet?
Thomas Peuss is working on a load balancer that would encompass this. You can see if there is code that is usable for you task. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Nathan Phelps" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, February 12, 2003 2:14 PM Subject: [JBoss-dev] HttpProxyServlet? > > I'm currently working with a client who uses IIS/ServletExec due to > legacy issues. IIS is bound to port 80 and 443 on the PC's one IP. The > firewall is only open on port 80 and 443 for the machine's one IP. Some > requests need to be serviced by IIS/ServletExec, while others need to be > serviced by Web/JBoss (Jetty). > > Therefore, we need to set up IIS/ServletExec to act as a proxy to > Web/JBoss running on the same machine on port 8080, taking requests on > port 80 or 443, reissuing them Web/JBoss (Jetty) on port 8080 and > returning the response to the client. I.E. HttpProxyServlet? > > I started writing one for my very specific use case, but figured it may > be a more useful addition if it were more generalized and could handle > *any* HTTP or HTTPS requests. Has anyone got something like this? > > Thanks, > > Nathan > > > > --- > 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
RE: [JBoss-dev] TxInterceptor split is bad
> Actually the code is much more readable. I guess my > only concern now is > non-java/jboss clients. And, do we care? > Non java code will have a seperate server-side invoker and it should deal with the TX stuff as best it can. In otherwords, do it the old way if it works better for corba. > Another thing about this is that you're requiring > the client to become > beafier and beafier. I've been kinda nervous about > the whole JMX on the > client sort of thing and the start of deploying > services on the client side. > But maybe it doesn't matter. > Ahh.. but that's the future. Unfortuanly, smarter clients means beefier clients. The chalenge will be to setup the plumbing that will allows us to create those smart clients without having to worry about thier size and distribution. In other words, the plumbing should take care of the heavy/stale proxy problem. > Bill > > P.S. Good to see you around again Hiram. > I went back to using an online mail service. Checking email only at night would really kill my response times. Regards, Hiram __ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com --- 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
RE: [JBoss-dev] TxInterceptor split is bad AND broken?
Ok, I see where the Transaction gets stuffed into the invocation object. Still no tm.resume though for user transactions. Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Bill > Burke > Sent: Wednesday, February 12, 2003 6:06 PM > To: [EMAIL PROTECTED] > Cc: David Jencks > Subject: RE: [JBoss-dev] TxInterceptor split is bad AND broken? > > > Ok, I'm looking at the code further and I'm pretty confused on how a > Transaction get propagated across the wire now. Can you explain? I don't > see any code anywhere that is doing a tm.resume from the > transaction that is > past across the wire. Is this code broken? > > Bill > > > > -Original Message- > > From: Bill Burke [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, February 12, 2003 5:51 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] TxInterceptor split is bad > > > > > > Another thing David, > > > > I don't see you always stuffing the Transaction into the > > invocation object. A few interceptors rely on the transaction > > being in the invocation object. Any objects to fixing this? > > > > Bill > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED]]On > Behalf Of Bill > > > Burke > > > Sent: Wednesday, February 12, 2003 5:36 PM > > > To: [EMAIL PROTECTED] > > > Subject: RE: [JBoss-dev] TxInterceptor split is bad > > > > > > > > > > > > > > > > -Original Message- > > > > From: [EMAIL PROTECTED] > > > > [mailto:[EMAIL PROTECTED]]On > > Behalf Of Hiram > > > > Chirino > > > > Sent: Wednesday, February 12, 2003 5:09 PM > > > > To: [EMAIL PROTECTED]; David Jencks > > > > Subject: Re: [JBoss-dev] TxInterceptor split is bad > > > > > > > > > > > > --- Bill Burke <[EMAIL PROTECTED]> wrote: > > > > > What if you don't have java on the client side? > > > > > What if you're CORBA with > > > > > OTS? You're making it harder for Non-JBoss/Java > > > > > clients to integrated with > > > > > us. I think this split should be undone. > > > > > > > > > > > > > How des OTS work? The corba guys tackled the DTM > > > > problem too right?? > > > > > > > > > > They have the concept of a ThreadLocal (Current) (My knowledge > > > is probably > > > outdated and foggy). In O2K the client side interceptor stuffs > > the value > > > from the transaction current into the IIOP service context, > > much the same > > > way we used to do before David's switch. > > > > > > -1 for refactor > > > > > > > > BTW, why the split besides code readability? Is the > > > > > DTM dependent on this > > > > > at all? Is the TM even accessed on the client side? > > > > > > > > > > > > > I think so. In the case were a client is a server the > > > > local TM is accessed to treat the remote TM like a > > > > XAResource. > > > > > > > > > > +1 for refactor > > > > > > > > Another problem I see is that the TxMethod map is > > > > > required on the client > > > > > side as well. Makes proxies even more heavy and > > > > > what do you do about a hot > > > > > deploy? > > > > > > > > > > > > > Yes.. but same argument could be made against any > > > > client side interceptor we create. The proxy on the > > > > client goes stale if a redeploy changes the proxy > > > > config. > > > > > > > > > > Ok, you're right. +2 for refactor > > > > > > > > Seems to me this is a bad idea. > > > > > > > > > > > > > I agree it is a complex solution. But the DTM problem > > > > is complex too. Any simpler sugestions?? > > > > > > > > > > Actually the code is much more readable. I guess my only > concern now is > > > non-java/jboss clients. And, do we care? > > > > > > Another thing about this is that you're requiring the client to become > > > beafier and beafier. I've been kinda nervous about the whole > JMX on the > > > client sort of thing and the start of deploying services on the > > > client side. > > > But maybe it doesn't matter. > > > > > > Bill > > > > > > P.S. Good to see you around again Hiram. > > > > > > > > > > > > --- > > > 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:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-
RE: [JBoss-dev] TxInterceptor split is bad AND broken?
The transaction is not getting propagated across the wire. A new XID is what is getting propagated. Remember that an XID != the tx. The relationship is that a tx will have multiple XIDs (one ore each resource that is involved in the tx). David is treating the remote jboss server like any other transacted resource. He enists the XAResource of the remote server, and gives that XAResource a new XID. Since remote tm is providing an XAResource interface to the remote tx, the local tm can commit/rollback the remote tx via a 2pc. David, I hope that was accurate since I have not really looked at your code! Regards, Hiram --- Bill Burke <[EMAIL PROTECTED]> wrote: > Ok, I'm looking at the code further and I'm pretty > confused on how a > Transaction get propagated across the wire now. Can > you explain? I don't > see any code anywhere that is doing a tm.resume from > the transaction that is > past across the wire. Is this code broken? > > Bill > > > > -Original Message- > > From: Bill Burke [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, February 12, 2003 5:51 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] TxInterceptor split is > bad > > > > > > Another thing David, > > > > I don't see you always stuffing the Transaction > into the > > invocation object. A few interceptors rely on the > transaction > > being in the invocation object. Any objects to > fixing this? > > > > Bill > > > > > -Original Message- > > > From: > [EMAIL PROTECTED] > > > > [mailto:[EMAIL PROTECTED]]On > Behalf Of Bill > > > Burke > > > Sent: Wednesday, February 12, 2003 5:36 PM > > > To: [EMAIL PROTECTED] > > > Subject: RE: [JBoss-dev] TxInterceptor split is > bad > > > > > > > > > > > > > > > > -Original Message- > > > > From: > [EMAIL PROTECTED] > > > > > [mailto:[EMAIL PROTECTED]]On > > Behalf Of Hiram > > > > Chirino > > > > Sent: Wednesday, February 12, 2003 5:09 PM > > > > To: [EMAIL PROTECTED]; > David Jencks > > > > Subject: Re: [JBoss-dev] TxInterceptor split > is bad > > > > > > > > > > > > --- Bill Burke <[EMAIL PROTECTED]> wrote: > > > > > What if you don't have java on the client > side? > > > > > What if you're CORBA with > > > > > OTS? You're making it harder for > Non-JBoss/Java > > > > > clients to integrated with > > > > > us. I think this split should be undone. > > > > > > > > > > > > > How des OTS work? The corba guys tackled the > DTM > > > > problem too right?? > > > > > > > > > > They have the concept of a ThreadLocal (Current) > (My knowledge > > > is probably > > > outdated and foggy). In O2K the client side > interceptor stuffs > > the value > > > from the transaction current into the IIOP > service context, > > much the same > > > way we used to do before David's switch. > > > > > > -1 for refactor > > > > > > > > BTW, why the split besides code readability? > Is the > > > > > DTM dependent on this > > > > > at all? Is the TM even accessed on the > client side? > > > > > > > > > > > > > I think so. In the case were a client is a > server the > > > > local TM is accessed to treat the remote TM > like a > > > > XAResource. > > > > > > > > > > +1 for refactor > > > > > > > > Another problem I see is that the TxMethod > map is > > > > > required on the client > > > > > side as well. Makes proxies even more heavy > and > > > > > what do you do about a hot > > > > > deploy? > > > > > > > > > > > > > Yes.. but same argument could be made against > any > > > > client side interceptor we create. The proxy > on the > > > > client goes stale if a redeploy changes the > proxy > > > > config. > > > > > > > > > > Ok, you're right. +2 for refactor > > > > > > > > Seems to me this is a bad idea. > > > > > > > > > > > > > I agree it is a complex solution. But the DTM > problem > > > > is complex too. Any simpler sugestions?? > > > > > > > > > > Actually the code is much more readable. I > guess my only concern now is > > > non-java/jboss clients. And, do we care? > > > > > > Another thing about this is that you're > requiring the client to become > > > beafier and beafier. I've been kinda nervous > about the whole JMX on the > > > client sort of thing and the start of deploying > services on the > > > client side. > > > But maybe it doesn't matter. > > > > > > Bill > > > > > > P.S. Good to see you around again Hiram. > > > > > > > > > > > > > --- > > > 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
[JBoss-dev] PTC resettable fuse
P T C Resettable fuses www.wanreihe.com Dear maddam or sir: (sorry for interupting you) When traditional fuses being used for overcurrent protection,they only can protect one time,once being blown out they must be replaced,but the PTC resettable fuses as the new type overcurrent protection products have the double fountions of overcurrent protection and automatic restoration. Our PTC resetable fuse is serially connected in the circuit,under normal circumstances it presents low resistence state and can ensure the normal work of the circuit.In case of occuring short circuit or unsually high current,the heat in the fuse is strong enough to make its impendance increasing to limit current very low,so playing the role for protecting the circuit.After fixing the fault,PTC element will automatically return to its low resistance state. Compared to the traditional fuse,PTC prossesses the advantages of resettable,little volume and solidness. Best whises for you ! ¡¡ ÄúºÃ! ÉîÛÚÊÐÍòÈðºÍµç×ÓÓÐÏÞ¹«Ë¾ÊÇÒ»¼ÒרҵÉú²ú¸ß·Ö×ÓPTC×Ô»Ö¸´±£ÏÕË¿µÄ¸ßм¼ÊõÆóÒµ£¬¹«Ë¾ÓµÓÐÍêÕûµÄÖÊÁ¿±£Ö¤Ìåϵ£¬ÒÑͨ¹ýISO9001ÖÊÁ¿ÌåϵÈÏÖ¤¡£Í¬Ê±¹«Ë¾²úƷҲͨ¹ýCE¡¢³¤³Ç¡¢T¨¹vµÈ¶àÏîÈÏÖ¤ºÍÐÅÏ¢²úÒµ²¿Í¨ÐŲúÆ··À»¤ÐÔÄÜÖÊÁ¿¼ì²â¡£ ¡¡ÍòºÍ×Ô¸´±£ÏÕË¿´®ÁªÔÚµç·ÖУ¬Õý³£Çé¿öϳʵÍ×è״̬£¬µ±µç·¶Ì·»ò´®ÈëÒì³£´óµçÁ÷ʱ£¬×Ô¸´±£ÏÕË¿ÔںܶÌʱ¼äÄÚ±ä³É¸ß×è״̬£¬´Ó¶ø¶Ôµç·Æðµ½±£»¤×÷Ó㬵±Òì³£Ïû³ýºó£¬×Ô¸´±£ÏÕË¿ÓÖ×Ô¶¯»Ö¸´µ½µÍ×è״̬£¬ÎÞÐèÈËΪ¸ü»»»òάÐÞ¡£ ÓÐÒâÕß»¶ÓÀ´µçÀ´ÐÅ×Éѯ¡¢Ç¢Ì¸. ×££º ÉÌì÷£¡ Miss Gan hongmei ADD£ºCaitian Road ,Shenzhen,Guangdong province,China TEL:(0086)-0755-82913072 FAX:(0086)-0755-82914490 E-mail:[EMAIL PROTECTED] HTTP://www.wanreihe.com ¡¡ --- 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
RE: [JBoss-dev] TxInterceptor split is bad AND broken?
I don't see where the tm.resume happens to associate the transaction with the current thread. The old UserTransaction stuff is still there in JRMPInvokerProxy and JRMPInvoker (importTPC and such), but the logic to associate the thread on the server with the transaction is not there anymore unless it is hidden someplace. Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Hiram > Chirino > Sent: Wednesday, February 12, 2003 7:31 PM > To: [EMAIL PROTECTED] > Cc: David Jencks > Subject: RE: [JBoss-dev] TxInterceptor split is bad AND broken? > > > The transaction is not getting propagated across the > wire. A new XID is what is getting propagated. > Remember that an XID != the tx. The relationship is > that a tx will have multiple XIDs (one ore each > resource that is involved in the tx). > > David is treating the remote jboss server like any > other transacted resource. He enists the XAResource > of the remote server, and gives that XAResource a new > XID. > > Since remote tm is providing an XAResource interface > to the remote tx, the local tm can commit/rollback the > remote tx via a 2pc. > > David, I hope that was accurate since I have not > really looked at your code! > > Regards, > Hiram > --- Bill Burke <[EMAIL PROTECTED]> wrote: > > Ok, I'm looking at the code further and I'm pretty > > confused on how a > > Transaction get propagated across the wire now. Can > > you explain? I don't > > see any code anywhere that is doing a tm.resume from > > the transaction that is > > past across the wire. Is this code broken? > > > > Bill > > > > > > > -Original Message- > > > From: Bill Burke [mailto:[EMAIL PROTECTED]] > > > Sent: Wednesday, February 12, 2003 5:51 PM > > > To: [EMAIL PROTECTED] > > > Subject: RE: [JBoss-dev] TxInterceptor split is > > bad > > > > > > > > > Another thing David, > > > > > > I don't see you always stuffing the Transaction > > into the > > > invocation object. A few interceptors rely on the > > transaction > > > being in the invocation object. Any objects to > > fixing this? > > > > > > Bill > > > > > > > -Original Message- > > > > From: > > [EMAIL PROTECTED] > > > > > > > [mailto:[EMAIL PROTECTED]]On > > Behalf Of Bill > > > > Burke > > > > Sent: Wednesday, February 12, 2003 5:36 PM > > > > To: [EMAIL PROTECTED] > > > > Subject: RE: [JBoss-dev] TxInterceptor split is > > bad > > > > > > > > > > > > > > > > > > > > > -Original Message- > > > > > From: > > [EMAIL PROTECTED] > > > > > > > > [mailto:[EMAIL PROTECTED]]On > > > Behalf Of Hiram > > > > > Chirino > > > > > Sent: Wednesday, February 12, 2003 5:09 PM > > > > > To: [EMAIL PROTECTED]; > > David Jencks > > > > > Subject: Re: [JBoss-dev] TxInterceptor split > > is bad > > > > > > > > > > > > > > > --- Bill Burke <[EMAIL PROTECTED]> wrote: > > > > > > What if you don't have java on the client > > side? > > > > > > What if you're CORBA with > > > > > > OTS? You're making it harder for > > Non-JBoss/Java > > > > > > clients to integrated with > > > > > > us. I think this split should be undone. > > > > > > > > > > > > > > > > How des OTS work? The corba guys tackled the > > DTM > > > > > problem too right?? > > > > > > > > > > > > > They have the concept of a ThreadLocal (Current) > > (My knowledge > > > > is probably > > > > outdated and foggy). In O2K the client side > > interceptor stuffs > > > the value > > > > from the transaction current into the IIOP > > service context, > > > much the same > > > > way we used to do before David's switch. > > > > > > > > -1 for refactor > > > > > > > > > > BTW, why the split besides code readability? > > Is the > > > > > > DTM dependent on this > > > > > > at all? Is the TM even accessed on the > > client side? > > > > > > > > > > > > > > > > I think so. In the case were a client is a > > server the > > > > > local TM is accessed to treat the remote TM > > like a > > > > > XAResource. > > > > > > > > > > > > > +1 for refactor > > > > > > > > > > Another problem I see is that the TxMethod > > map is > > > > > > required on the client > > > > > > side as well. Makes proxies even more heavy > > and > > > > > > what do you do about a hot > > > > > > deploy? > > > > > > > > > > > > > > > > Yes.. but same argument could be made against > > any > > > > > client side interceptor we create. The proxy > > on the > > > > > client goes stale if a redeploy changes the > > proxy > > > > > config. > > > > > > > > > > > > > Ok, you're right. +2 for refactor > > > > > > > > > > Seems to me this is a bad idea. > > > > > > > > > > > > > > > > I agree it is a complex solution. But the DTM > > problem > > > > > is complex too. Any simpler sugestions?? > > > > > > > > > > > > > Actually the code is much more readable. I > > guess my only concern now is > > > > non-java/jboss clients. And, do we care? > > > > > > > > Another thing about this is that you're > > requiring the client to become > > > > beafier and beafier.
[JBoss-dev] 3.2 - WebIntegrationUnitTestCase failure
One test currently fails : 01:00:50,842 INFO [jbossweb] Error compiling file: /tmp/Jetty_0_0_0_0_8080__jbosstest/classpath_jsp.java [javac] Compiling 1 source file /tmp/Jetty_0_0_0_0_8080__jbosstest/classpath_jsp.java:135: cannot resolve symbol symbol : class EJBStats location: package j2ee Class clazz2 = javax.management.j2ee.EJBStats.class; I'm running the 'all' config. The class in question appears in the following places : [jules@zeuglodon jboss-3.2]$ for i in `find build/output/jboss-3.2.0RC2/ -name "*.jar" -type f` > do > $JAVA_HOME/bin/jar tvf $i | grep EJBStats\.class && echo $i > done 280 Thu Feb 13 00:56:18 GMT 2003 javax/management/j2ee/statistics/EJBStats.class build/output/jboss-3.2.0RC2/client/jboss-jsr77-client.jar 280 Thu Feb 13 00:56:18 GMT 2003 javax/management/j2ee/statistics/EJBStats.class build/output/jboss-3.2.0RC2/client/jbossall-client.jar 280 Thu Feb 13 00:56:18 GMT 2003 javax/management/j2ee/statistics/EJBStats.class build/output/jboss-3.2.0RC2/server/all/lib/jboss-jsr77.jar 280 Thu Feb 13 00:56:18 GMT 2003 javax/management/j2ee/statistics/EJBStats.class build/output/jboss-3.2.0RC2/server/default/lib/jboss-jsr77.jar [jules@zeuglodon jboss-3.2]$ But, whilst it is present in build/output/jboss-3.2.0RC2/server/all/lib/jboss-jsr77.jar which is in Jasper's classpath, the package name appears to have changed from avax.management.j2ee.EJBStats to avax/management/j2ee/statistics/EJBStats If this is the case, shall I fix it?, or is something that requires deeper thought going on ? Jules --- 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
Re: [JBoss-dev] 3.2 - WebIntegrationUnitTestCase failure
I just fixed it. Thanks for pointing out the issue. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Jules Gosnell" <[EMAIL PROTECTED]> To: "jboss-development" <[EMAIL PROTECTED]> Sent: Wednesday, February 12, 2003 5:17 PM Subject: [JBoss-dev] 3.2 - WebIntegrationUnitTestCase failure > One test currently fails : > > 01:00:50,842 INFO [jbossweb] Error compiling file: > /tmp/Jetty_0_0_0_0_8080__jbosstest/classpath_jsp.java [javac] > Compiling 1 source file > > /tmp/Jetty_0_0_0_0_8080__jbosstest/classpath_jsp.java:135: cannot > resolve symbol > symbol : class EJBStats > location: package j2ee >Class clazz2 = javax.management.j2ee.EJBStats.class; > > I'm running the 'all' config. > > The class in question appears in the following places : > > [jules@zeuglodon jboss-3.2]$ for i in `find build/output/jboss-3.2.0RC2/ > -name "*.jar" -type f` > > do > > $JAVA_HOME/bin/jar tvf $i | grep EJBStats\.class && echo $i > > done > 280 Thu Feb 13 00:56:18 GMT 2003 > javax/management/j2ee/statistics/EJBStats.class > build/output/jboss-3.2.0RC2/client/jboss-jsr77-client.jar > 280 Thu Feb 13 00:56:18 GMT 2003 > javax/management/j2ee/statistics/EJBStats.class > build/output/jboss-3.2.0RC2/client/jbossall-client.jar > 280 Thu Feb 13 00:56:18 GMT 2003 > javax/management/j2ee/statistics/EJBStats.class > build/output/jboss-3.2.0RC2/server/all/lib/jboss-jsr77.jar > 280 Thu Feb 13 00:56:18 GMT 2003 > javax/management/j2ee/statistics/EJBStats.class > build/output/jboss-3.2.0RC2/server/default/lib/jboss-jsr77.jar > [jules@zeuglodon jboss-3.2]$ > > But, whilst it is present in > build/output/jboss-3.2.0RC2/server/all/lib/jboss-jsr77.jar which is in > Jasper's classpath, the package name appears to have changed from > avax.management.j2ee.EJBStats to avax/management/j2ee/statistics/EJBStats > > If this is the case, shall I fix it?, or is something that requires > deeper thought going on ? > > Jules > > > > --- > 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
[JBoss-dev] Web containers and jsr77
There are two layers of integration between web containers and JSR77 model components I want to implement for 3.2 The first is the JSR77 WebModule which is handled at the AbstractWebContainer level. Subclasses of AbstractWebContainer need to populate the DeploymentInfo.mbeans list with the JMX ObjectNames of the war's servlets managment objects. If the container is not creating JMX objects for the servlets just place the name of the servlet in there. The more problematic model is the ServletStats which requires access to the following time statistics on a servlet's service method: - long minTime in milliseconds - long maxTime in milliseconds - long totalTime in milliseconds This does require the servlet container to create a MBean facade that provides this information. This should be the MBean whose name is added to the DeploymentInfo.mbean list. How big a deal is this going to be to add support for Jetty and Tomcat? Scott Stark Chief Technology Officer JBoss Group, LLC --- 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
Re: [JBoss-dev] TxInterceptor split is bad
In this case the client side method to tx support map uses MethodHash values as keys since the Methods themselves are not serializable. Seems to me that we should put the MethodHash values in the invocation to start with. david On 2003.02.12 17:57 Scott M Stark wrote: > > Another problem I see is that the TxMethod map is required on the > client > > side as well. Makes proxies even more heavy and what do you do about a > hot > > deploy? > > The hot deploy is a general issue with proxies. Whether or not this works > depends > on the transport endpoint. RMI/JRMP proxies do not work across a hot > deploy, > and most p2p transports do not. Making the proxies more robust across hot > deploys > using our own transports, etc. is something we should work towards. > > A java.lang.reflect.Method map is a very anti-hot-deploy construct > because of the > strong typing of the Method to its class. We should certainly look to > limit the exposure > of such a mapping outside of the VM. > > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > > > - Original Message - > From: "Bill Burke" <[EMAIL PROTECTED]> > To: "David Jencks" <[EMAIL PROTECTED]>; "Jboss-Dev" > <[EMAIL PROTECTED]> > Sent: Wednesday, February 12, 2003 1:31 PM > Subject: [JBoss-dev] TxInterceptor split is bad > > > > What if you don't have java on the client side? What if you're CORBA > with > > OTS? You're making it harder for Non-JBoss/Java clients to integrated > with > > us. I think this split should be undone. > > > > BTW, why the split besides code readability? Is the DTM dependent on > this > > at all? Is the TM even accessed on the client side? > > > > > > --- > 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
RE: [JBoss-dev] TxInterceptor split is bad
I still want to understand why there needs to be a TxSupport.clientInvoke. Please bring your thoughts/design public. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of David > Jencks > Sent: Wednesday, February 12, 2003 10:17 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] TxInterceptor split is bad > > > In this case the client side method to tx support map uses MethodHash > values as keys since the Methods themselves are not serializable. > Seems to > me that we should put the MethodHash values in the invocation to start > with. > > david > > On 2003.02.12 17:57 Scott M Stark wrote: > > > Another problem I see is that the TxMethod map is required on the > > client > > > side as well. Makes proxies even more heavy and what do you > do about a > > hot > > > deploy? > > > > The hot deploy is a general issue with proxies. Whether or not > this works > > depends > > on the transport endpoint. RMI/JRMP proxies do not work across a hot > > deploy, > > and most p2p transports do not. Making the proxies more robust > across hot > > deploys > > using our own transports, etc. is something we should work towards. > > > > A java.lang.reflect.Method map is a very anti-hot-deploy construct > > because of the > > strong typing of the Method to its class. We should certainly look to > > limit the exposure > > of such a mapping outside of the VM. > > > > > > Scott Stark > > Chief Technology Officer > > JBoss Group, LLC > > > > > > - Original Message - > > From: "Bill Burke" <[EMAIL PROTECTED]> > > To: "David Jencks" <[EMAIL PROTECTED]>; "Jboss-Dev" > > <[EMAIL PROTECTED]> > > Sent: Wednesday, February 12, 2003 1:31 PM > > Subject: [JBoss-dev] TxInterceptor split is bad > > > > > > > What if you don't have java on the client side? What if you're CORBA > > with > > > OTS? You're making it harder for Non-JBoss/Java clients to integrated > > with > > > us. I think this split should be undone. > > > > > > BTW, why the split besides code readability? Is the DTM dependent on > > this > > > at all? Is the TM even accessed on the client side? > > > > > > > > > > > --- > > 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:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] TxInterceptor split is bad
Ok, that is good. Yes we need to limit the use of the most strongly typed components to where absolutely necessary to improve the robustness of the framework level components. A MethodHash should not change across hot deployments unless the method signature has changed and I believe this is the case today as we don't include any class identity info like hashCodes do we? Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "David Jencks" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, February 12, 2003 7:16 PM Subject: Re: [JBoss-dev] TxInterceptor split is bad > In this case the client side method to tx support map uses MethodHash > values as keys since the Methods themselves are not serializable. Seems to > me that we should put the MethodHash values in the invocation to start > with. > > david --- 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
Re: [JBoss-dev] TxInterceptor split is really really good
The design goal is to produce a working dtm that does not make unnecesary inter-vm calls. The functionality of the client side tx interceptor appears to be unavailable with the CORBA OTS if we do not write some client side stuff. Here is the sequence of events for a call between vms where a transaction is started on the client (could be a standalone app or a JBoss instance) client starts tx client calls ejb proxy client side tx interceptor attaches tx to invocation ONLY if tx support for the method is supports, mandatory, or requires. In all other cases it makes sure no tx is attached to the invocation. invocation is routed to correct transport mechanism (such as by the HA Invoker interceptor)(AFAIK not yet written as an interceptor) Now that we have the target jboss instance determined, the InvokerXAResource enlists with the tx if present, thus getting an xid to transport. If no tx is present, it doesnt enlist with null. The xid is sent over the transport mechanism with the marshalled invocation. The server-side half of the transport mechanism/invoker extracts the xid if present, puts in in an ExcecutionContext, and uses the WorkManager associated with the invoker to execute the call to the ejb. The WorkManager communicates with the server-side tx manager to start and end the transaction at the beginning and end of the call. The method returns. At some later time, the tx commits. Since the InvokerXAResource was enlisted in the tx IF AND ONLY IF the tx was actually sent to do work on the server jboss instance, it will get a commit call only if the server jboss instance actually did work in the tx. If it did work in the tx, it gets (possible) prepare and commit calls with the xid for its branch, and makes a invocation to call an XATerminatorContainer, which has the same method call syntax as an ejb container. In any case it handles communicating the prepare and commit calls to the server-side tx manager. -- Of course, with optimized in-vm calls, you don't have an InvokerXAResource and don't generate an xid for the method call. -- Now lets consider the alternative. Without knowing the tx support of every method in the ejb, EVERY transaction MUST be ALWAYS enlisted with the InvokerXAResource, have an xid generated for it, get transmitted over the transport mechansim, and enrolled in the server-side transaction manager. Then when commit comes, totally useless prepare and commit calls must be made to a remote vm for a transaction that COULD NOT POSSIBLY HAVE DONE ANY WORK. We have one remote call to do the requested work and up to two calls to no purpose. It may seem unlikely that a small client would start a user transaction and then call an ejb method that didn't use it, but it seems considerably less implausible to me that a jboss server would call, within a transaction, a remote ejb with a non-transactional method. Looking at the OTS 1.2 spec, I notice that they do not use xids to identify branches. The tx support model appears to only support the equivalent of never, supports, and mandatory. Therefore, if a tx is present in an invocation, either an exception will be thrown or it will be used. Although no xid can be supplied by the OTS, jboss will still be responsible for calling coordinator.register_resource(jboss-resource) back in the corba client. I have no idea how the remote part of corba works, but it would obviously be advantageous to have something analogous to the InvokerXAResource in the client making this call rather than requiring a call back from jboss. david jencks On 2003.02.12 16:31 Bill Burke wrote: > What if you don't have java on the client side? What if you're CORBA > with > OTS? You're making it harder for Non-JBoss/Java clients to integrated > with > us. I think this split should be undone. > > BTW, why the split besides code readability? Is the DTM dependent on > this > at all? Is the TM even accessed on the client side? > > Another problem I see is that the TxMethod map is required on the client > side as well. Makes proxies even more heavy and what do you do about a > hot > deploy? > > Seems to me this is a bad idea. > > Bill > > > > --- > 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
[JBoss-dev] [ jboss-Change Notes-685731 ] Container Managed Audit Fields
Change Notes item #685731, was opened at 2003-02-13 05:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=381174&aid=685731&group_id=22866 Category: JBossCMP Group: v3.2 Status: Open Priority: 5 Submitted By: Adrian Brock (ejort) Assigned to: Nobody/Anonymous (nobody) Summary: Container Managed Audit Fields Initial Comment: Initial support for Container Managed Audit Fields Initially in 3.2 for evaluation purposes. Coding this in CMP2 is a pain and requires calculating the values on every set, monitoring whether the set actually changed the value. In jbosscmp-jdbc.xml add to the relevent entity. Four new fields are maintained by the CMP engine audit_created_by, audit_created_time, audit_updated_by, audit_updated_time For created_by and updated_by the caller principal must be in the entity context otherwise they are blank. You can choose which of the fields you want to use e.g. You can change the column names as follows change_username> The field can also be a CMP field, by matching the field-name changedBy When the field is set programmatically this takes precedence over the container managed values. TODO 1) Decide and support relevent jdbc-type/sql-types. 2) Support date and time as separate fields for legacy data mappings 3) Add support for CMR tables. Regards, Adrian -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=381174&aid=685731&group_id=22866 --- 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
[JBoss-dev] JAR Deployer deploys subfolders in deploy
Hi, Just a heads up to see whether this change is deliberate? In 3.2, if you create a subfolder in server/[config]/deploy with deployables in it, the JARDeployer deploys them. e.g. server/default/deploy/dead/http-invoker.sar It doesn't deploy xml files. This doesn't happen in 3.0 I only noticed it because I sometimes move services into a "dead" folder within deploy to speed up reboot times when changing server code. Regards, Adrian _ Overloaded with spam? With MSN 8, you can filter it out http://join.msn.com/?page=features/junkmail&pgmarket=en-gb&XAPID=32&DI=1059 --- 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
Re: [JBoss-dev] JAR Deployer deploys subfolders in deploy
I thought 3.0 had this same behavior. In the last training someone had created a server/all/deploy/farm directory and placed an ejb-jar into this directory and it was deployed. I can see both behaviors being useful in different situations, but I'm not aware of what change in 3.2 would cause the behavior to differ if in fact it does. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Adrian Brock" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, February 12, 2003 9:33 PM Subject: [JBoss-dev] JAR Deployer deploys subfolders in deploy > Hi, > > Just a heads up to see whether this change is deliberate? > > In 3.2, if you create a subfolder in server/[config]/deploy with > deployables in it, the JARDeployer deploys them. > > e.g. server/default/deploy/dead/http-invoker.sar > > It doesn't deploy xml files. > > This doesn't happen in 3.0 > > I only noticed it because I sometimes move services > into a "dead" folder within deploy to speed up reboot times > when changing server code. > > Regards, > Adrian > > > _ > Overloaded with spam? With MSN 8, you can filter it out > http://join.msn.com/?page=features/junkmail&pgmarket=en-gb&XAPID=32&DI=1059 > > > > --- > 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
Re: [JBoss-dev] JAR Deployer deploys subfolders in deploy
Scott Stark wrote: I thought 3.0 had this same behavior. In the last training someone had created a server/all/deploy/farm directory and placed an ejb-jar into this directory and it was deployed. Ok, sorry for noise. I probably didn't spot it had started doing it until now? I actually delete the deployments more often than I move than them. :-) Regards, Adrian _ Express yourself with cool emoticons http://messenger.msn.co.uk --- 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
