[JBoss-dev] Jboss java.lang.VerifyError:
Hi, Iam getting the following exception, but its not consistent, When they occur if I clear the server all temp dir and restart the server it works fine, can any one help me out with this? :- JBoss version 3.0.0 integrated with tomcat 4.0.3 and JDK version is 1.3 [java.naming.provider.url:localhost:1099, java.naming.factory.initial:org.jnp.interfaces.NamingContextFactory, java.naming.factory.url.pkgs:org.jboss.naming] 07:03:05,729 INFO [DB] [EntityMetaInfoLoader.loadMetaInfoFor] Enter 07:03:15,223 ERROR [LogInterceptor] TransactionRolledbackException, causedBy: java.lang.VerifyError: Cannot inherit from final class at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:486) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:111) at java.net.URLClassLoader.defineClass(URLClassLoader.java:248) at java.net.URLClassLoader.access$100(URLClassLoader.java:56) at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at org.jboss.mx.loading.UnifiedClassLoader.findClass(UnifiedClassLoader.java:227) at java.lang.ClassLoader.loadClass(ClassLoader.java:297) at org.jboss.mx.loading.UnifiedClassLoader.loadClassLocally(UnifiedClassLoader.java:235) at org.jboss.mx.loading.UnifiedLoaderRepository.loadClassFromClassLoader(UnifiedLoaderRepository.java:361) at org.jboss.mx.loading.UnifiedLoaderRepository.loadClass(UnifiedLoaderRepository.java:140) at org.jboss.mx.loading.UnifiedClassLoader.loadClass(UnifiedClassLoader.java:285) at java.lang.ClassLoader.loadClass(ClassLoader.java:253) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:313) at com.gridnode.pdip.framework.db.DataObject.(DataObject.java:41) at com.gridnode.pdip.framework.db.entity.AbstractEntity.(AbstractEntity.java:86) at com.gridnode.pdip.base.gwfbase.baseentity.GWFProcess.(Unknown Source) at com.gridnode.pdip.base.gwfbase.xpdl.model.XpdlProcess.(Unknown Source) at java.lang.Class.newInstance0(Native Method) at java.lang.Class.newInstance(Class.java:237) _ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-693326 ] Deadlock between threads "main"/"JBoss Shutdown Hook"
Bugs item #693326, was opened at 2003-02-26 12:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=693326&group_id=22866 Category: JBossMX Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Brian Wallis (bwallis42) Assigned to: Nobody/Anonymous (nobody) Summary: Deadlock between threads "main"/"JBoss Shutdown Hook" Initial Comment: OS: Mandrake Linux 8.0 with Redhat 7.2 kernel (2.4.7-10) arch: i386 jdk: SUN JDK 1.4.1_01 JBoss Version: 3.0.4 While starting jboss for a test I realised I had forgotten something and hit control-C to shut it down again. The startup had got to starting deployment of jbossmq-service.xml when the shutdown began. It got as far as starting to undeploy jbossmq.jar and deadlocked The jboss server trace is attached in a file including a deadlock report from the JVM showing what is locked and why it is deadlocked. Reproducing this may be difficult, it is no doubt very timing sensitive to when the shutdown starts. There should be enough info in the thread stack traces to find the problem. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=693326&group_id=22866 --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-693311 ] getEJBLocalHome throws UnsupportedOperationException
Bugs item #693311, was opened at 2003-02-26 00:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=693311&group_id=22866 Category: JBossServer Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Mike Youngstrom (youngm) Assigned to: Nobody/Anonymous (nobody) Summary: getEJBLocalHome throws UnsupportedOperationException Initial Comment: Is there any plan to implement this method? Is there a reason why it's not implemented? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=693311&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-693239 ] JBoss ClassLoader implementation is unappropriate for EJB co
Bugs item #693239, was opened at 2003-02-25 23:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=693239&group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Thomas Pasch (aanno) Assigned to: Nobody/Anonymous (nobody) Summary: JBoss ClassLoader implementation is unappropriate for EJB co Initial Comment: The Problem -- EJB (jar), WEB (war), and enterprise (ear) archives should be isolated from another. This especially means that: (a) independant packed components could use different version of a file with the same qualified name (b) independant packed components could call each other (i.e. home, remote, and local interfaces) JBoss ClassLoader design will cache all Class instances globally in standard configuration. This violates (a). It is possible to switch to (ear) archive-wise caching. But this violates (b), because the (client interfaces) packed with component 1 will be loaded with a different ClassLoader than the interface definition packed in component 2 (that also implements the bean) if both components are deployed on the same JVM. Violation of (b) normally shows up in a ClassCastException in PortableRemoteObject.narrow(). In summary it is impossible in JBoss to adhere to (a) and (b) at the same time. Proposed solution -- There are two ways around this problem: - disable the local call optimisation for call between independant packed components or - use a IIOP like scheme for all calls. IIOP will only transfer data members of object instances. It will NOT share Class implementation between independant packed component. Kind regards, aanno -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=693239&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: Fixed 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] Automated JBoss(Branch_3_0) Testsuite Results: 25-February-2003
JBoss daily test results SUMMARY Number of tests run: 1049 Successful tests: 1044 Errors:1 Failures: 4 [time of test: 2003-02-25.12-05 GMT] [java.version: 1.3.1] [java.vendor: Apple Computer, Inc.] [java.vm.version: 1.3.1_03-69] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Mac OS X] [os.arch: ppc] [os.version: 10.2.4] See http://users.jboss.org/~starksm/Branch_3_0/2003-02-25.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: BaseConnectionManagerUnitTestCase Test:testFillToMin(org.jboss.test.jca.test.BaseConnectionManagerUnitTestCase) Type:failure Exception: junit.framework.AssertionFailedError Message: Wrong number of connections counted: 1 - Suite: MissingClassUnitTestCase Test: testDeployServiceWithoutClass(org.jboss.test.jmx.test.MissingClassUnitTestCase) Type:error Exception: org.jboss.deployment.DeploymentException Message: jboss.test:name=missingclasstest is not registered.; - nested throwable: (javax.management.InstanceNotFoundException: jboss.test:name=missingclasstest is not registered.) - Suite: SecurityUnitTestCase Test:testSecureHttpInvoker(org.jboss.test.naming.test.SecurityUnitTestCase) Type:failure Exception: junit.framework.AssertionFailedError Message: Should not have been able to lookup(invokers) - Suite: SecurityUnitTestCase Test: testSecureHttpInvokerFailure(org.jboss.test.naming.test.SecurityUnitTestCase) Type:failure Exception: junit.framework.AssertionFailedError Message: Should not have been able to lookup(invokers) - Suite: BeanStressTestCase Test:testDeadLockFromClient(org.jboss.test.deadlock.test.BeanStressTestCase) Type:failure Exception: junit.framework.AssertionFailedError Message: expected a client deadlock for AB BA - --- 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: Fixed 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 [ja
RE: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread
Oh, you just want invoker interceptors for generic tx importation. I guess this is fine. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Hiram > Chirino > Sent: Tuesday, February 25, 2003 1:10 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] TxInterceptor split is still the best thing > since sliced bread > > > I though what I sugested was KISS. Tx imporation is > currently done at the invoker level. I want to keep > it there but make it plugable via interceports at the > invoker level. > > I guess it would be more KISS to just duplicate the > code that is in the trunk invoker over to all ther > other java based transports. But that seems more > error prone to me. > > Regards, > Hiram > > --- Bill Burke <[EMAIL PROTECTED]> wrote: > > What I'm saying is, why add this complication? Do > > we really need it? KISS. > > -Original Message- > > From: > > [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] > > Behalf Of Hiram > > Chirino > > Sent: Tuesday, February 25, 2003 11:23 AM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] TxInterceptor split is > > still the best thing since > > sliced bread > > > > > > How about implementing some kind of seperate > > interceptor framwork around > > the client side and server side invocation layers?? > > > > David, if yoiu had a configurable way to plug in > > your tx interceptors at > > the invocation layer you would be ok right? I think > > david just needs to > > avoid duplicating the code that is in the trunk > > invoker all over the place. > > > > Bill, how doable is that? > > > > Regards, > > Hiram > > > >Bill Burke <[EMAIL PROTECTED]> wrote: > > > > > > > > IMHO, CORE client interceptors such as security > > and tx should be written > > such that if the client doesn't support > > interceptors (C++) you don't > > break > > the server side or put additional configuration > > requirements on the > > server > > side. > > > > > > Bill > > > > > > > > > > > > > > > > > > > -- > -- > > -- > > Do you Yahoo!? > > Yahoo! Tax Center - forms, calculators, tips, and > > more > > > > > __ > Do you Yahoo!? > Yahoo! Tax Center - forms, calculators, tips, more > http://taxes.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 --- 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 still the best thing since sliced bread
Maybe we're confusing 2 issues here: 1. writing a maintainable usable jboss dtm 2. supporting corba etc. I realize I am not entirely comfortable with the client interceptors, and I notice that they are not really used in the local proxies. I don't think my idea of using the client interceptors inside a corba invoker will work, because there will be no way to simulate a client environment. So I'm basically abandoning my idea of always using the same client interceptors for all clients including local, remote, and corba. I think the current client interceptor stack configuration system may be lousy and need redesign, but that is sort of a third question. I think it should not be tied to the invoker but to local/remote/corba choice. The fact that all client interceptor stacks today are identical supports this view. How about: server side interceptor gets back the functionality of suspending transactions that are not needed (for not supoorted and requires new) client side interceptor for remote client does this also, to avoid creating unneeded branches. Local clients won't need the client side tx interceptor. The corba clients will continue creating branches based on the corba transaction policy, and we will import all such transactions that arrive via corba immediately. The server side tx interceptor may suspend these tx in the case of notsupported and requiresNew. There's nothing we can do about the remote corba tm creating unneeded branches, and the simplest way to deal with them is simply to import them so when a prepare/commit/etc request comes we just let our tm deal with it. - (in reference to Hiram's comment) On the client side, I need 2 pieces of functionality: a tx-support aware interceptor per remote object (ejb name, not instance) and an xaresource per remote jboss server. I'm still convinced this is by far the simplest possible implementation for dtm. I think writing the xaresource as a transport-level interceptor will have many many simplifying advantages, but it is not necessary, only about half as complex as my previous solution. It could be written once and plugged in some other way, but I don't see the point in using an inferior architecture to an interceptor stack. Thanks 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 still the best thing since sliced bread
I though what I sugested was KISS. Tx imporation is currently done at the invoker level. I want to keep it there but make it plugable via interceports at the invoker level. I guess it would be more KISS to just duplicate the code that is in the trunk invoker over to all ther other java based transports. But that seems more error prone to me. Regards, Hiram --- Bill Burke <[EMAIL PROTECTED]> wrote: > What I'm saying is, why add this complication? Do > we really need it? KISS. > -Original Message- > From: > [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Behalf Of Hiram > Chirino > Sent: Tuesday, February 25, 2003 11:23 AM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] TxInterceptor split is > still the best thing since > sliced bread > > > How about implementing some kind of seperate > interceptor framwork around > the client side and server side invocation layers?? > > David, if yoiu had a configurable way to plug in > your tx interceptors at > the invocation layer you would be ok right? I think > david just needs to > avoid duplicating the code that is in the trunk > invoker all over the place. > > Bill, how doable is that? > > Regards, > Hiram > >Bill Burke <[EMAIL PROTECTED]> wrote: > > > > IMHO, CORE client interceptors such as security > and tx should be written > such that if the client doesn't support > interceptors (C++) you don't > break > the server side or put additional configuration > requirements on the > server > side. > > > Bill > > > > > > > > > > -- > Do you Yahoo!? > Yahoo! Tax Center - forms, calculators, tips, and > more > __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.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 still the best thing since sliced bread
What I'm saying is, why add this complication? Do we really need it? KISS. -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Hiram ChirinoSent: Tuesday, February 25, 2003 11:23 AMTo: [EMAIL PROTECTED]Subject: RE: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread How about implementing some kind of seperate interceptor framwork around the client side and server side invocation layers?? David, if yoiu had a configurable way to plug in your tx interceptors at the invocation layer you would be ok right? I think david just needs to avoid duplicating the code that is in the trunk invoker all over the place. Bill, how doable is that? Regards,Hiram Bill Burke <[EMAIL PROTECTED]> wrote: IMHO, CORE client interceptors such as security and tx should be writtensuch that if the client doesn't support interceptors (C++) you don't breakthe server side or put additional configuration requirements on the serverside.Bill Do you Yahoo!?Yahoo! Tax Center - forms, calculators, tips, and more
RE: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread
How about implementing some kind of seperate interceptor framwork around the client side and server side invocation layers?? David, if yoiu had a configurable way to plug in your tx interceptors at the invocation layer you would be ok right? I think david just needs to avoid duplicating the code that is in the trunk invoker all over the place. Bill, how doable is that? Regards,Hiram Bill Burke <[EMAIL PROTECTED]> wrote: IMHO, CORE client interceptors such as security and tx should be writtensuch that if the client doesn't support interceptors (C++) you don't breakthe server side or put additional configuration requirements on the serverside.BillDo you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, and more
RE: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of David > Jencks > Sent: Monday, February 24, 2003 3:02 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] TxInterceptor split is still the best thing > since sliced bread > > > On 2003.02.24 14:35 Bill Burke wrote: > > > > > > > > > > Bill, what I find really boring and unpleasant about this > discussion is > > > that I can't find any evidence that you read most of my posts, or that > > you > > > > Ditto. > > > > I thought I did read your stuff and replied appropriately. Maybe I > > missed > > something. What I saw you propose for non-Java and I'll quote you: > > > > "outside world >>> something corba and proxy-like > ci1 > ci2 > > some kind > > of > > invoker-like thing > si1 > si2 > actual target object" > > > > My argument against this was that you would have to maintain 2 separate > > interceptor chains on the server. > > > > For IIOP the chain would be (as you stated) > > > > IIOPInvoker > ci1 > ci2 > si1 > si2 > actual target object. > > > > For RMI/Java the chain would be > > > > DP > ci1 > ci2 > network --- JRMPInvoker > si1 > si2 > > > > I voiced a similar problem with AOP where the AOP interceptors > would have > > to > > know whether the call had traveled through a remote proxy object. > > I wrote the lengthy description/picture below in an attempt to find out > what you are talking about, since this argument doesn't make sense to me. > I didn't see any response from you about it. > > I'll try to explain why, specifically, your argument makes no sense to me. > > I think interceptors all implement required functionality. If > you put them > in the chain, it's for a reason: they are doing something you need. > Therefore, however many transport steps are in the middle, any invocation > should go through the same (target specific) interceptors. (IMO transport > layer interceptors on both ends are a good idea too, but that's a separate > argument). If the interceptor chains have different > interceptors, you will > get different behavior, and you should be getting that through other means > such as additional deployments. > > Therefore, for a conceptual interceptor chain of ci1 > ci2 > si1 > si2, > this might end up as > > ci1 > ci2 > ||transport from client machine to server || > si1 > si2 > > target object. > > or > > ci1 > ci2 > ||do nothing "transport" on same machine || > si1 > si2 > > target object. > > It might be possible to arrange for > > ci1 > ci2 > si1 > si2 > target object but I don't see why you'd want to > particularly. > > Furthermore, for corba, > > java-corba-endpoint on server > ci1 > ci2 > || possible "transport" > translation layer whose need is questionable || > si1 > si2 > target > object. > What I"m saying is that you've created a need for this construct with the split in TxSupport of clientINvoke and serverInvoke. With your current design, ci1 needs the EJB's trans-attribute method map. Thus we need 2 different interceptor chains on the server to service IIOP and JRMP. With the current architecture this interceptor chain requirement wouldn't allow the same EJB target object to service calls from both IIOP and JRMP at the same time. You would have to create two separate EJBs with two different Container Configurations. Here's what it would look like in reality with an endpoint target object with id 1223 C++ Client -- network --- endpoint Invoker> MBean invoke > SERVER SIDE CHAIN: ci Tx > ci2 > si 1 > si 2 > 1223 Target Object Java client > DP > ci Tx > ci2 --- network -- Invoker > Mbean invoke > si1 > si2 > 1223 Target Object Look at the configuration in standardjboss.xml. The configuration for client and server side interceptors are separate. If you would configure the above example in XML you would see that you would be defining 2 separate chains and as a result, you would not be able to have the same Target object receive requests from 2 separate For JBoss 3.2 and 3.0. All the tx interceptor did was propagate the transaction. This interceptor is not needed for a C++ iiop client because the IIOP transport does the propagation for you. Thus you have no need to > To me these are all the same interceptor chain: they all have the same > members, with the exception of the one missing any kind of transport. The > chain has 2 entry points: ci1 and si1. If you regard this as > more than one > interceptor chain please explain your point of view. As I understand it, > this is also essentially how we handle ejbs today: certainly we maintain > both the client and server interceptor stacks on the server. > It is not the same chain. Do the actual XML configuration remembering that a C++ IIOP client does not have client-side interceptors. You will find that in no way will you be able to define configuration such that one target object can receive requests from multiple transports at the same time with the current architecture. Maybe we eventually need to
RE: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread
> well, aside from my and babelfish's inability to translate that... Yeah... That's because I did a mistake... Shame... It is not "Ortille", but "Ortie", which means "nettle". That gives: "Maybe I am pushing Grand Mother in the nettles" (i.e. maybe I go too far...) > 1. I was planning to move the invocation reassembly and > targeting into a > bunch of interceptors on the server side. Ok, so my loosy argument is in fact something you wanted to do ;) > 2. I think your argument applies with exactly equal force to > the client > side interceptors and if we put the functionality for IIOP > into the invoker > on the server side we should for exactly the same reason > eliminate client > side interceptors everywhere and put them in the client side of "more > capable" (than IIOP) invokers. No, that's not what I mean. I meant that with IIOP we have *no* way to do something on the client-side anyway i.e. with IIOP we are *forced* to do everything on the server side. Nevertheless, because IIOP imply that does *not* mean that it should dictate it for java clients able to use client side interceptor. Don't forget that CSI (client side interceptors) are not only used to populate information in the invocation but also to get information from the client side JVM/environment. Oviously, this cannot be mimic'ed on the server side. > Just because we haven't used > the client > interceptors for any customization doesn't mean they aren't a > good idea. Sure. > If we ever found a use for including additional context > information, we > would be able to include it in all transports simply be > writing one client > and one server interceptor and adding it to the chains for > the objects we > wanted it for. For IIOP, I think this would result in the > fewest changes: > I think basically we'd just have to add the C++ (or whatever) > code to send > the additional context info. OK, but, again, in this case, the SSI (server side interceptor) is only used to do something useful: the extraction of the context information can be done in a generic way inside the invoker (or any other object that satisfy a lambda design pattern...): the "IIOP-packet"-to-"JBoss-Invocation-object" conversion must take place at a single place as once the conversion is done, we forget about the original IIOP packet. Sorry if what I say is a non-sense for DTMs: I am really focused on a specific case: non-necessarly-Java IIOP clients. Am I making (partial) sense? Cheers, Sacha --- 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 still the best thing sincesliced bread
Interceptors seem reasonable, as long as there are no hidden costs behind them. Why not keep them seperated and more flexible? Also allows invokers to become a little bit simpler. The only down (aside from any performance & client-side class loading issues) are the read code as a story fluff which some of us have been pimping from day one. So that really isn't a down after all since I never bought into that garbage in the first place ;) So are there any performance or other negative side effects which would be undesirable by making this seperation? If not, then the more flexible and pluggable the better I say. But then again what do I know, I haven't touched a bit of code in months :( Only evil servers to deal with... --jason On Tue, 25 Feb 2003, David Jencks wrote: > On 2003.02.25 02:58 Sacha Labourey wrote: > > Hello, > > > > This discussion is somehow strange because, and I agree with David: you > > don't seem to be speaking about the same thing at the same time... > > Asynchronous argumentation is hard to follow... > > > > - I think we should have interceptors > > - Yes, but the sky is blue > > - No! Invokers can't handle DTM in this case > > - You mean AOP? > > > > I understand David's point of view. David loves orthogonal designs and > > the > > idea to have somehow symetric interceptors (between the client and the > > server), possibly with a null invoker in the middle of the chain makes > > his > > design pleaseant. Nevertheless, where I think I agree with Bill is that > > we > > first have to check if we don't go too far just for the beauty of it. > > Let's > > take IIOP as an example. In the general case, IIOP can only transport the > > same kind of data: > > - invocations information (method name, arguments, etc.) > > - arbitrary context information > > > > In the arbitrary payload, you may find security information, transaction > > information, etc. The question is: at the end of the day, do we really > > need > > a stack of interceptors just to extract this set of information and > > populate > > a JBoss invocation object? Couldnt we more simply just extract "all this > > stuff" and put it in the Invocation Object (and the server side Invoker > > could do that). > > > > I agree, it would look much smarter to have this "separation of concern" > > and > > have each interceptor from a virtual-client-stack (i.e. client side > > interceptors living on the server and mimic-ing client-side behaviour) > > put > > only what is needed inside the JBoss invocation object. NEVERTHELESS, as > > this information will always be similar, why not simply do that in a > > generic > > way inside the invoker: in-mass population of the invocation with > > well-known > > key names for well-known invocation content. > > > > If you think about it, the invoker already does that: it extracts the > > target > > MBean ObjectName from the invocation and push the invocation to it: if > > you > > push your reasoning far enough, that's already a concern that shouldn't > > be > > put in a pure "transport-focused invoker". But I agree, and as French > > say: > > "Je pousse mémé dans les ortilles". Translation left as an exercise. > > well, aside from my and babelfish's inability to translate that... > > 1. I was planning to move the invocation reassembly and targeting into a > bunch of interceptors on the server side. > > 2. I think your argument applies with exactly equal force to the client > side interceptors and if we put the functionality for IIOP into the invoker > on the server side we should for exactly the same reason eliminate client > side interceptors everywhere and put them in the client side of "more > capable" (than IIOP) invokers. Just because we haven't used the client > interceptors for any customization doesn't mean they aren't a good idea. > If we ever found a use for including additional context information, we > would be able to include it in all transports simply be writing one client > and one server interceptor and adding it to the chains for the objects we > wanted it for. For IIOP, I think this would result in the fewest changes: > I think basically we'd just have to add the C++ (or whatever) code to send > the additional context info. > > thanks > david > > > > > > Cheers, > > > > > > Sacha > > > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] On > > > Behalf Of David Jencks > > > Sent: lundi, 24. février 2003 21:02 > > > To: [EMAIL PROTECTED] > > > Subject: RE: [JBoss-dev] TxInterceptor split is still the > > > best thing since sliced bread > > > > > > > > > On 2003.02.24 14:35 Bill Burke wrote: > > > > > > > > > > > > > > > > > > Bill, what I find really boring and unpleasant about this > > > discussion is > > > > > that I can't find any evidence that you read most of my > > > posts, or that > > > > you > > > > > > > > Ditto. > > > > > > > > I thought I did read your stuf
RE: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread
On 2003.02.25 02:58 Sacha Labourey wrote: > Hello, > > This discussion is somehow strange because, and I agree with David: you > don't seem to be speaking about the same thing at the same time... > Asynchronous argumentation is hard to follow... > > - I think we should have interceptors > - Yes, but the sky is blue > - No! Invokers can't handle DTM in this case > - You mean AOP? > > I understand David's point of view. David loves orthogonal designs and > the > idea to have somehow symetric interceptors (between the client and the > server), possibly with a null invoker in the middle of the chain makes > his > design pleaseant. Nevertheless, where I think I agree with Bill is that > we > first have to check if we don't go too far just for the beauty of it. > Let's > take IIOP as an example. In the general case, IIOP can only transport the > same kind of data: > - invocations information (method name, arguments, etc.) > - arbitrary context information > > In the arbitrary payload, you may find security information, transaction > information, etc. The question is: at the end of the day, do we really > need > a stack of interceptors just to extract this set of information and > populate > a JBoss invocation object? Couldnt we more simply just extract "all this > stuff" and put it in the Invocation Object (and the server side Invoker > could do that). > > I agree, it would look much smarter to have this "separation of concern" > and > have each interceptor from a virtual-client-stack (i.e. client side > interceptors living on the server and mimic-ing client-side behaviour) > put > only what is needed inside the JBoss invocation object. NEVERTHELESS, as > this information will always be similar, why not simply do that in a > generic > way inside the invoker: in-mass population of the invocation with > well-known > key names for well-known invocation content. > > If you think about it, the invoker already does that: it extracts the > target > MBean ObjectName from the invocation and push the invocation to it: if > you > push your reasoning far enough, that's already a concern that shouldn't > be > put in a pure "transport-focused invoker". But I agree, and as French > say: > "Je pousse mémé dans les ortilles". Translation left as an exercise. well, aside from my and babelfish's inability to translate that... 1. I was planning to move the invocation reassembly and targeting into a bunch of interceptors on the server side. 2. I think your argument applies with exactly equal force to the client side interceptors and if we put the functionality for IIOP into the invoker on the server side we should for exactly the same reason eliminate client side interceptors everywhere and put them in the client side of "more capable" (than IIOP) invokers. Just because we haven't used the client interceptors for any customization doesn't mean they aren't a good idea. If we ever found a use for including additional context information, we would be able to include it in all transports simply be writing one client and one server interceptor and adding it to the chains for the objects we wanted it for. For IIOP, I think this would result in the fewest changes: I think basically we'd just have to add the C++ (or whatever) code to send the additional context info. thanks david > > Cheers, > > > Sacha > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On > > Behalf Of David Jencks > > Sent: lundi, 24. février 2003 21:02 > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] TxInterceptor split is still the > > best thing since sliced bread > > > > > > On 2003.02.24 14:35 Bill Burke wrote: > > > > > > > > > > > > > > Bill, what I find really boring and unpleasant about this > > discussion is > > > > that I can't find any evidence that you read most of my > > posts, or that > > > you > > > > > > Ditto. > > > > > > I thought I did read your stuff and replied appropriately. Maybe I > > > missed > > > something. What I saw you propose for non-Java and I'll quote you: > > > > > > "outside world >>> something corba and proxy-like > ci1 > > > ci2 > some kind > > > of > > > invoker-like thing > si1 > si2 > actual target object" > > > > > > My argument against this was that you would have to > > maintain 2 separate > > > interceptor chains on the server. > > > > > > For IIOP the chain would be (as you stated) > > > > > > IIOPInvoker > ci1 > ci2 > si1 > si2 > actual target object. > > > > > > For RMI/Java the chain would be > > > > > > DP > ci1 > ci2 > network --- JRMPInvoker > si1 > si2 > > > > > > I voiced a similar problem with AOP where the AOP > > interceptors would have > > > to > > > know whether the call had traveled through a remote proxy object. > > > > I wrote the lengthy description/picture below in an attempt > > to find out > > what you are talking about, since this argument doesn't make > > sense to me. > > I di
[JBoss-dev] Orkestra kuculdu ve cebinize girdi!
Title: SMSNET MELODI GRAFIK HABERLER 24 Þubat 2003www.melodilerim.com / www.grafiklerim.com Allý Turnam Gülpembe - Barýþ Manço Arap Saçý - Erkin Koray Bir Kulunu Çok Sevdim - Ýbrahim Tatlýses Alyazmalým - Cahit Berkay Kum Gibi - Ahmet Kaya Düþler Sokaðý -Ezginin Günlüðü Whenever Wherever - Shakira Mezdeke Mission Impossible Ve daha niceleri Melodilerim.com' da ORKESTRA küçüldü, küçüldü, küçüldü... CEBÝNÝZE GÝRDÝ !Polifonik melodiler, GPRS veya WAP yoluyla polifonik özelliði olan cep telefonunuza indirebileceðiniz, þimdiye kadar alýþýk olduðunuz melodilerden farklý olarak birden fazla enstrümanýn kullanýldýðý çok sesli melodilerdir. En önemli özellikleri, orijinal hallerine daha çok benzemeleridir.Polifonik melodilerimizi dinlemek, hangi telefon modellerine gönderilebildiðini öðrenmek ve telefonunuza transfer etmek için týklayýnýz...Sayfalarýmýzdaki yeniliklerimizi göremiyorsanýz, lütfen melodilerim.com sayfamýzý bir kaç kez üstüste yeniden yükleyiniz (Tazele / Refresh) ya da CTRL ve F5 tuþuna ayný anda basarak sayfamýzýn yeniden yüklenmesini saðlayýnýz.Melodi isteðinde bulunmak istiyorum!Resmimi telefonumda görmek istiyorum!Þifremi unuttumHaber listenizden çýkmak istiyorum Yardým hattýmýz: 0 312 2865891 (her gün 9.00 - 20.00 arasý) --- 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] 企业网络工程
企业如何应用计算机互联网进行网上的营销活动 电子邮件推广作为互联网上最有效的宣传模式，怎样搜索有价值的信息？如何找到更多的潜在客户？如何让更多的客户了解您？一切都变得简单。 在广告效果、价格、效率几方面的综合评测表明，其性价比均高出报纸和电视广告的数百倍乃至上千倍。 作为一家专业从事商业电子邮件服务的网络公司，我们一直致力于帮助中小企业创造网上直销及广告宣传新领域，优质的服务获得了广泛的好评。 一 [邮件地址出售] 全国7000万邮件地址： 全部7000万/500元 （国内个人用户Email地址共计7000万） 全国2000万分行业、地区企业邮件地址： 全部2000万/1080元 （经过精心筛选，过滤。均为国内企业用户，从精心搜集整理而来，27个大类和上百个小类，并经过专人在线校验，正确性绝对保证！企业邮件库的Email基本上都是各企业对外联系业务所使用的信箱，所以推广产品联系业务成功率极高。） 台湾250万邮件地址： 全部250万/600元 香港760万邮件地址： 全部760万/800元 国际2400万邮件地址： 全部2400万/1000元 （分为136个国家、40个行业） [邮件软件] 著名邮件发送、搜索软件： 全部注册版 价格：450元（功能最强大的邮件搜索、批量发送、验校、退订软件） 专为企业网络电子商务服务。他主要是解决商务邮件发送效率低的问题。支持SMTP中继与内置两种服务器.采用多线程对多服务器进行轮流同时发送,一次可以发送多个 Email地址列表文件,极大提高了邮件的发送速度,进行合理的发送配置,发送速度可高达30~200万/小时. 让您能短时间在互联网上指定区域并成千上万的发送出自己的广告邮件，其正版总价格超过万元。 [邮件代理发送] 全国指定行业，地区广告邮件发送： 每10万/100元 30万起发 （有效率90%以上） 全国指定行业，地区广告邮件发送： 100万/750元 全国指定行业，地区广告邮件发送： 500万发送/3000元（并保证网站日访问量提升1） 二 [邮件推广企业套餐用户]： 基本宣传型 600元 ・提供全国7000万邮件地址；著名邮件发送及搜索软件。 标准宣传型 1200元 ・全国2000万分行业、地区邮件地址；著名邮件发送及搜索软件。 白金宣传型 1600元 ・全国7000万邮件地址；全国2000万分行业、地区邮件地址；著名邮件发送及搜索软件。 黄金宣传型 2100元 ・全国7000万邮件地址；全国2000万分行业、地区邮件地址；著名邮件发送及搜索软件；搜索引擎注册、信息发布软件。 三 [搜索引擎注册] 帮你登陆全球一万?英文搜索引擎，进200个中文搜索引擎，让你的网站享誉全球。（超值服务，特惠价300） 四 [网络信息发布] 可以将您的销售，购买，招商或合作等商业信息自动发布到世界知名的3300多个贸易公告板和国内上千个BBS，论坛公告等。最大限度提升你的商业机会。（超值价400元） 联系及付款方式： 本公司从事网络广告多年，积累了丰富经验并有专门的技术人员和高速专业的服务系统从事此项工作，必将为您的企业提供最迅捷、最有效、最满意的服务。 同时支持全球分国家、地区英文信件发送及港、澳、台繁体广告信件发送。 具体详情请点击这里 欢迎来电咨询联系0816-6623109 交付方式：邮件、软件提供相关下载地址及软件注册。 需要EMS邮寄光盘及发票者，需加50元。具体详情请点击这里 晶资源网络服务中心 咨询电话：0816-6623109 传 真：0816-2210496 --- 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-692817 ] JDBCOptimisticLock fails under heavy load
Bugs item #692817, was opened at 2003-02-25 09:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=692817&group_id=22866 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Simone (milasx) Assigned to: Nobody/Anonymous (nobody) Summary: JDBCOptimisticLock fails under heavy load Initial Comment: JBoss 3.2.0 RC1 Windows NT 4 Solaris 8 JDK 1.4.1_01 0) In standardjboss.xml set org.jboss.ejb.plugins.lock.JDBCOptimisticLock 1) Define an Entity Bean with an associated Value Object (Xdoclet) 2) Define a finder method 3) Implement an EJB Session Facade to the Entity Bean 4) In the session facade provide a facade to the finder that return an array of Value Object 5) Call the session facade repetedly. 6) Some of the call will fails with Exception: javax.ejb.EJBException: Reentrant method call detected: YourEntityBean 4592 at org.jboss.ejb.plugins.EntityReentranceInterceptor.invoke(EntityReentranceInterceptor.java:82) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=692817&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-692157 ] UnifiedClassLoader.getResources not working
Bugs item #692157, was opened at 2003-02-24 10:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=692157&group_id=22866 Category: JBossMX Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Laurent Wozniak (lwozniak) Assigned to: Nobody/Anonymous (nobody) Summary: UnifiedClassLoader.getResources not working Initial Comment: Hello, I've just moved from JBoss 2.4.x to 3.0.x (3.0.4) and found the following bug: UnifiedClassLoader.getResources() does not return all the resources under a specific name. UnifiedClassLoader.getResource() can return a value while UnifiedClassLoader.getResources() is returning an empty enumeration for the same resource. I looked in the source code and found that: * UnifiedClassLoader inherit from URLClassLoader * UnifiedClassLoader override getResource() * UnifiedClassLoader does not override getResources() java.lang.ClassLoader.getResources() is final but it calls findResources() which is not. UnifiedClassLoader.findResources() is simply not implemented. LoaderRepository does not implement this functionnality either. I've implemented the missing methods, now it works fine on my local workstation. But I don't know what I'm supposed to do to give you the modifications I made. Cheers, Laurent -- >Comment By: Laurent Wozniak (lwozniak) Date: 2003-02-25 09:21 Message: Logged In: YES user_id=719431 Here is the patch. I've created it following the rules found at: http://www.netbeans.org/devhome/community/contrib-patches.html -- Comment By: Juha Lindfors (juhalindfors) Date: 2003-02-24 12:13 Message: Logged In: YES user_id=175239 create a diff of your local modified version against the version in the CVS and attach it -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=692157&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
RE: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread
Hello, This discussion is somehow strange because, and I agree with David: you don't seem to be speaking about the same thing at the same time... Asynchronous argumentation is hard to follow... - I think we should have interceptors - Yes, but the sky is blue - No! Invokers can't handle DTM in this case - You mean AOP? I understand David's point of view. David loves orthogonal designs and the idea to have somehow symetric interceptors (between the client and the server), possibly with a null invoker in the middle of the chain makes his design pleaseant. Nevertheless, where I think I agree with Bill is that we first have to check if we don't go too far just for the beauty of it. Let's take IIOP as an example. In the general case, IIOP can only transport the same kind of data: - invocations information (method name, arguments, etc.) - arbitrary context information In the arbitrary payload, you may find security information, transaction information, etc. The question is: at the end of the day, do we really need a stack of interceptors just to extract this set of information and populate a JBoss invocation object? Couldnt we more simply just extract "all this stuff" and put it in the Invocation Object (and the server side Invoker could do that). I agree, it would look much smarter to have this "separation of concern" and have each interceptor from a virtual-client-stack (i.e. client side interceptors living on the server and mimic-ing client-side behaviour) put only what is needed inside the JBoss invocation object. NEVERTHELESS, as this information will always be similar, why not simply do that in a generic way inside the invoker: in-mass population of the invocation with well-known key names for well-known invocation content. If you think about it, the invoker already does that: it extracts the target MBean ObjectName from the invocation and push the invocation to it: if you push your reasoning far enough, that's already a concern that shouldn't be put in a pure "transport-focused invoker". But I agree, and as French say: "Je pousse mémé dans les ortilles". Translation left as an exercise. Cheers, Sacha > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of David Jencks > Sent: lundi, 24. février 2003 21:02 > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] TxInterceptor split is still the > best thing since sliced bread > > > On 2003.02.24 14:35 Bill Burke wrote: > > > > > > > > > > Bill, what I find really boring and unpleasant about this > discussion is > > > that I can't find any evidence that you read most of my > posts, or that > > you > > > > Ditto. > > > > I thought I did read your stuff and replied appropriately. Maybe I > > missed > > something. What I saw you propose for non-Java and I'll quote you: > > > > "outside world >>> something corba and proxy-like > ci1 > > ci2 > some kind > > of > > invoker-like thing > si1 > si2 > actual target object" > > > > My argument against this was that you would have to > maintain 2 separate > > interceptor chains on the server. > > > > For IIOP the chain would be (as you stated) > > > > IIOPInvoker > ci1 > ci2 > si1 > si2 > actual target object. > > > > For RMI/Java the chain would be > > > > DP > ci1 > ci2 > network --- JRMPInvoker > si1 > si2 > > > > I voiced a similar problem with AOP where the AOP > interceptors would have > > to > > know whether the call had traveled through a remote proxy object. > > I wrote the lengthy description/picture below in an attempt > to find out > what you are talking about, since this argument doesn't make > sense to me. > I didn't see any response from you about it. > > I'll try to explain why, specifically, your argument makes no > sense to me. > > I think interceptors all implement required functionality. > If you put them > in the chain, it's for a reason: they are doing something you need. > Therefore, however many transport steps are in the middle, > any invocation > should go through the same (target specific) interceptors. > (IMO transport > layer interceptors on both ends are a good idea too, but > that's a separate > argument). If the interceptor chains have different > interceptors, you will > get different behavior, and you should be getting that > through other means > such as additional deployments. > > Therefore, for a conceptual interceptor chain of ci1 > ci2 > > si1 > si2, > this might end up as > > ci1 > ci2 > ||transport from client machine to server || > si1 > si2 > > target object. > > or > > ci1 > ci2 > ||do nothing "transport" on same machine || > si1 > si2 > > target object. > > It might be possible to arrange for > > ci1 > ci2 > si1 > si2 > target object but I don't see why > you'd want to > particularly. > > Furthermore, for corba, > > java-corba-endpoint on server > ci1 > ci2 > || possible "transport" > translation layer whose need is questionable || > si1 > s
