[JBoss-dev] [ jboss-Bugs-686611 ] throwsRemoteException in AbstractVerifier
Bugs item #686611, was opened at 2003-02-14 17:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=686611&group_id=22866 Category: JBossServer Group: None Status: Open Resolution: None Priority: 5 Submitted By: roberto (rroberto) >Assigned to: Christian Riege (lqd) Summary: throwsRemoteException in AbstractVerifier Initial Comment: According to the RMI Spec. a remote interface must throw a RemoteException so, I need to make sure that the exception thrown is either a RemoteException or a class that can be assigned to RemoteException (a derived class). Using if( exception[i].isAssignableFrom (java.rmi.RemoteException.class) ) this is not fully correct.. I suggest to replace with : if (java.rmi.RemoteException.class.isAssignableFrom (exception[i])) This problem occurs with 3.0.6 Thank You Roberto -- >Comment By: Christian Riege (lqd) Date: 2003-02-25 06:09 Message: Logged In: YES user_id=176671 ... i vaguely remember there being a reason why the test is carried around this way (IIRC it was initially done the other way around and changed because of some other bug). i'll take a look at this. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=686611&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] Verifier problems
hi, On Sat, 2003-02-22 at 02:42, Dain Sundstrom wrote: > I'm working on fixing the exception tests and I have run into a problem > with the verifier. I am getting the following warning that is causing > the deployment to fail: > > Bean : ExceptionTesterEJB > Method : public abstract void ejbExceptionInStore() throws Exception > Section: 7.10.7 > Warning: The methods in the local interface must not include > java.rmi.RemoteException in their throws clause. > > I don't think they wanted to exclude 'throws Exception' from a > declaration. This is really a grey area of the spec. > > Who is maintaining this code? What do you think? i'm maintainig the code. can you file a bug report on sf.net against me (lqd) and attach a testcase? i thought i fixed something like this at the end of last year, what JBoss version are you trying this on? i also remember seeing a bug report on sf.net about this; however my net access has been crappy for the past two weeks. improving now though, i'll be back on track in the next two-three days. best regards, christian --- 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-688624 ] Classloader mixes static objects
Bugs item #688624, was opened at 2003-02-18 12:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=688624&group_id=22866 Category: None Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Rami Hänninen (rajualf) >Assigned to: David Jencks (d_jencks) Summary: Classloader mixes static objects Initial Comment: JBoss Release: JBoss-3.0.4 CVSTag=JBoss_3_0_4 Java version: 1.3.1_01,Sun Microsystems Inc. Java VM: Java HotSpot(TM) Server VM 1.3.1_01,Sun Microsystems Inc. OS-System: Linux 2.4.18-3,i386 While running several versions of closely related Web Applications in a JBoss server, I found out that JBoss classloaders mix static method invokations and data accross different web applications. The problem occurs at least in jboss-3.0.4_tomcat-4.0.6 and jboss-3.0.0_tomcat-4.0.3. The problem manifests itself when the server contains two web applications that both contain a different version of the same class, and the classes contain the same static method, and a different version of the same private static final object. The bug is, that if the static methods reference the private static final object, they always get a reference to the object from the class residing in the application THAT WAS DEPLOYED FIRST. The method in the class residing in the application deployed last gets therefore access to an invalid object, taken from a wrong web application scope. Included is a tar-ball containing two simple WAR -files that demonstrate the problem. Please deploy 'a.war' first, and note that 'http:/localhost/a' reports a string originating from application 'A'. Deploy then 'b.war', and note, that 'http:/localhost/b' reports that the is string also originates from application 'A' (should be 'B'). Remove then both, and deploy first 'B' and then 'A' to reverse the situation. -- >Comment By: David Jencks (d_jencks) Date: 2003-02-25 03:02 Message: Logged In: YES user_id=60525 This behavior IMO is expected. I think relying on static fields or methods in an app server is not going to work well no matter what you do. For instance, what if you cluster your app? I'm surprised your apps didn't crash quickly with LoaderContraints violations. However, to get the behavior you want in one jboss instance, you must deploy each application in an .ear file and include a jboss-app.xml that specifies a unique loader repository. This will get each app in a classloader space that cannot see the other. I'm closing this issue. If you try the above and it does not work please ask on a mailing list before reopening. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=688624&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-692398 ] CachedConnectionManager.unregisterConnection
Bugs item #692398, was opened at 2003-02-24 18:40 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=692398&group_id=22866 Category: JBossServer Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Paul W. Ward (pward) >Assigned to: David Jencks (d_jencks) Summary: CachedConnectionManager.unregisterConnection Initial Comment: CachedConnectionManager.unregisterConnection throws an IllegalStateException when the connection being unregistered is not the first connection in the map. The throw of "Trying to return an unknown connection2!" should be moved to after the for loop it's currently sitting in. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=692398&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-690506 ] 3.2.0RC2 xa_start error -8 with SQLServer
Bugs item #690506, was opened at 2003-02-21 05:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=690506&group_id=22866 Category: JBossTX Group: v3.2 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Marc Prud'hommeaux (mprudhom) >Assigned to: David Jencks (d_jencks) Summary: 3.2.0RC2 xa_start error -8 with SQLServer Initial Comment: When attempting to commit an XA transaction using SQLServer (using the MS driver, configured using the mssql-xa-ds.xml DS configured in the examples), it works fine the first time. The second time, it throws "javax.transaction.xa.XAException: [Microsoft][SQLServer 2000 Driver for JDBC][SQLServer]xa_start (0) returns -8". According to section 4.5 of the X/Open XA specification, -8 indicates "the XID already exists", which indicates that JBoss may be re-using XIDs inappropriately. The exact same code worked for JBoss 3.2.0 beta 3. System info: [chance mprudhom]$ java -version java version "1.3.1" Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-root_1.3.1_020714-12:46) Java HotSpot(TM) Client VM (build 1.3.1_03-69, mixed mode) [chance mprudhom]$ uname -a Darwin chance.local. 6.4 Darwin Kernel Version 6.4: Wed Jan 29 18:50:42 PST 2003; root:xnu/xnu-344.26.obj~1/RELEASE_PPC Power Macintosh powerpc Stack trace: 19:29:19,487 WARN [TransactionImpl] XAException: tx=TransactionImpl:XidImpl [FormatId=257, GlobalId=chance.local.//8, BranchQual=] errorCode=XAER_RMERR javax.transaction.xa.XAException: [Microsoft][SQLServer 2000 Driver for JDBC][SQLServer]xa_start (0) returns -8 at com.microsoft.jdbcx.sqlserver.SQLServerImplXAResource.executeXaRpc(Unknown Source) at com.microsoft.jdbcx.sqlserver.SQLServerImplXAResource.start(Unknown Source) at com.microsoft.jdbcx.base.BaseXAResource.start(Unknown Source) at org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:110) at org.jboss.tm.TransactionImpl.startResource(TransactionImpl.java:1137) at org.jboss.tm.TransactionImpl.enlistResource(TransactionImpl.java:624) at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:461) at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:359) at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:546) at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:837) at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:102) at com.solarmetric.kodo.impl.jdbc.runtime.DataSourceConnector.getConnection(DataSourceConnector.java:61) at com.solarmetric.kodo.impl.jdbc.schema.DBDictionaryFactory.getDictionary(DBDictionaryFactory.java:179) at com.solarmetric.kodo.impl.jdbc.JDBCSimpleConfiguration.getDictionary(JDBCSimpleConfiguration.java:336) at com.solarmetric.kodo.impl.jdbc.JDBCPersistenceManagerFactory.registerClassInternal(JDBCPersistenceManagerFactory.java:454) at com.solarmetric.kodo.impl.jdbc.JDBCPersistenceManagerFactory.registerClass(JDBCPersistenceManagerFactory.java:337) at com.solarmetric.kodo.impl.jdbc.RegisterListener.registerClass(RegisterListener.java:53) at javax.jdo.spi.JDOImplHelper.registerClass(JDOImplHelper.java:269) at com.solarmetric.kodo.runtime.AllFieldTypesTest.(AllFieldTypesTest.java) at XAEnvironmentTest.testXATransaction(XAEnvironmentTest.java:99) at XAEnvironmentTest.testXATransaction(XAEnvironmentTest.java:72) at XAEnvironmentTest.start(XAEnvironmentTest.java:323) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:966) at $Proxy11.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:392) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) at $Proxy5.start(Unknown Source) at org.jboss.deployment.SARDeployer.start(SARDeployer.java:231) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:827) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:639) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:612) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.
[JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed
= ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net FOR DETAILS= = JAVA VERSION DETAILS java version "1.3.1_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_06-b01) Java HotSpot(TM) Server VM (build 1.3.1_06-b01, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE org.jboss.ejb.EJBDeployer --> EJBDeployerMBean qualified to EJBDeployerMBean org.jboss.ejb.ContainerPlugin --> Service qualified to Service org.jboss.ejb.InstanceCache --> StatisticsProvider qualified to StatisticsProvider org.jboss.ejb.EntityEnterpriseContext --> EJBContextImpl qualified to EJBContextImpl org.jboss.invocation.Invoker --> Remote qualified to Remote org.jboss.ejb.StatefulSessionContainer --> AbstractContainerInterceptor qualified to AbstractContainerInterceptor org.jboss.ejb.EjbModule --> EjbModuleMBean qualified to EjbModuleMBean org.jboss.ejb.plugins.StatefulSessionFilePersistenceManager --> StatefulSessionFilePersistenceManagerMBean qualified to StatefulSessionFilePersistenceManagerMBean org.jboss.ejb.timer.AbstractTimerSource --> AbstractTimerSourceMBean qualified to AbstractTimerSourceMBean org.jboss.ejb.timer.FilePersistenceManager --> FilePersistenceManagerMBean qualified to FilePersistenceManagerMBean org.jboss.ejb.timer.SchedulerTimerSource --> SchedulerTimerSourceMBean qualified to SchedulerTimerSourceMBean org.jboss.invocation.InvokerXAResource --> InvokerXAResourceMBean qualified to InvokerXAResourceMBean org.jboss.invocation.XATerminatorContainer --> XATerminatorContainerMBean qualified to XATerminatorContainerMBean org.jboss.invocation.http.server.HttpInvokerMBean --> ServiceMBean qualified to ServiceMBean org.jboss.invocation.local.LocalInvoker --> LocalInvokerMBean qualified to LocalInvokerMBean org.jboss.invocation.jrmp.server.JRMPInvoker --> JRMPInvokerMBean qualified to JRMPInvokerMBean org.jboss.invocation.pooled.server.PooledInvoker --> PooledInvokerMBean qualified to PooledInvokerMBean org.jboss.invocation.trunk.client.ConnectionManager --> ConnectionManagerMBean qualified to ConnectionManagerMBean org.jboss.invocation.trunk.client.TrunkInvokerProxy --> TrunkInvokerProxyMBean qualified to TrunkInvokerProxyMBean org.jboss.invocation.trunk.server.TrunkInvoker --> TrunkInvokerMBean qualified to TrunkInvokerMBean org.jboss.jms.asf.ServerSessionPoolLoader --> ServerSessionPoolLoaderMBean qualified to ServerSessionPoolLoaderMBean org.jboss.jms.jndi.JMSProviderLoader --> JMSProviderLoaderMBean qualified to JMSProviderLoaderMBean org.jboss.jmx.connector.RemoteMBeanServer --> MBeanServer qualified to MBeanServer org.jboss.jmx.connector.notification.JMSNotificationListener --> JMSNotificationListenerMBean qualified to JMSNotificationListenerMBean org.jboss.jmx.connector.notification.RMINotificationListener --> RMINotificationListenerMBean qualified to RMINotificationListenerMBean org.jboss.jmx.adaptor.rmi.RMIAdaptorService --> RMIAdaptorServiceMBean qualified to RMIAdaptorServiceMBean org.jboss.jmx.adaptor.xml.XMLAdaptorService --> XMLAdaptorServiceMBean qualified to XMLAdaptorServiceMBean org.jboss.jmx.adaptor.xml.XMLTestService --> XMLTestServiceMBean qualified to XMLTestServiceMBean org.jboss.jmx.connector.rmi.RMIConnectorImpl --> RMIConnectorImplMBean qualified to RMIConnectorImplMBean org.jboss.jmx.connector.ejb.EJBConnector --> EJBConnectorMBean qualified to EJBConnectorMBean org.jboss.jmx.connector.ConnectorFactoryService --> ConnectorFactoryServiceMBean qualified to ConnectorFactoryServiceMBean org.jboss.jmx.connector.notification.PollingNotificationListener --> PollingNotificationListenerMBean qualified to PollingNotificationListenerMBean org.jboss.logging.Log4jService --> Log4jServiceMBean qualified to Log4jServiceMBean org.jboss.logging.Log4jSocketServer --> Log4jSocketServerMBean qualified to Log4jSocketServerMBean org.jboss.naming.ExternalContext --> ExternalContextMBean qualified to ExternalContextMBean org.jboss.naming.JNDIView --> JNDIViewMBean qualified to JNDIViewMBean org.jboss.naming.NamingAlias --> NamingAliasMBean qualified to NamingAliasMBean org.jboss.naming.NamingService --> NamingServiceMBean qualified to NamingServiceMBean org.jboss.web.AbstractWebContainer --> AbstractWebContainerMBean qualified to AbstractWebContainerMBean WARNING: Some classes refer to other classes that were not found among the sources or on the classpath. (Perhaps the referred class doesn't exist? Hasn't been generated yet?) The referring classes do not import any fully qualified classes matching these classes. Since at least one package is imported, it is impossible for xjavadoc to figure out what package the referred classes belong to. The classes are: org.jboss.web.WebService --> WebServiceMBean qualified to WebSer
Re: [JBoss-dev] Patch for jboss/jetty CLIENT-CERT authentication
We've put this into CVS (Branch_3_[02]). Please confirm that eveything does as you would expect (we don't have a testcase) and keep the patches coming. Thanks, Jules Dawes, Phil wrote: Hi Jboss/Jetty team, Apologies for not submitting this through the patch manager. I wasn't sure where to put it, since jbossweb/jetty isn't a category. I've attached a patch against jboss-3.0.6/jetty to add CLIENT-CERT authentication via HTTPS or AJP13. It also fixes a bug against the Jetty AJP13 Cert handling code. This patch uses the jbosssx api to expose the certificate chain to the JAAS login module as the credential of a SecurityAssocationCallback. It also fixes a bug in the Jetty AJP13 code which put the client cert into the request object as a string (it should be an X509Certificate[]). Cheers, Phil -- If you have received this e-mail in error or wish to read our e-mail disclaimer statement and monitoring policy, please refer to http://www.drkw.com/disc/email/ or contact the sender. -- --- 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-690506 ] 3.2.0RC2 xa_start error -8 with SQLServer
Bugs item #690506, was opened at 2003-02-21 00:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=690506&group_id=22866 Category: JBossTX Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Marc Prud'hommeaux (mprudhom) Assigned to: Nobody/Anonymous (nobody) Summary: 3.2.0RC2 xa_start error -8 with SQLServer Initial Comment: When attempting to commit an XA transaction using SQLServer (using the MS driver, configured using the mssql-xa-ds.xml DS configured in the examples), it works fine the first time. The second time, it throws "javax.transaction.xa.XAException: [Microsoft][SQLServer 2000 Driver for JDBC][SQLServer]xa_start (0) returns -8". According to section 4.5 of the X/Open XA specification, -8 indicates "the XID already exists", which indicates that JBoss may be re-using XIDs inappropriately. The exact same code worked for JBoss 3.2.0 beta 3. System info: [chance mprudhom]$ java -version java version "1.3.1" Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-root_1.3.1_020714-12:46) Java HotSpot(TM) Client VM (build 1.3.1_03-69, mixed mode) [chance mprudhom]$ uname -a Darwin chance.local. 6.4 Darwin Kernel Version 6.4: Wed Jan 29 18:50:42 PST 2003; root:xnu/xnu-344.26.obj~1/RELEASE_PPC Power Macintosh powerpc Stack trace: 19:29:19,487 WARN [TransactionImpl] XAException: tx=TransactionImpl:XidImpl [FormatId=257, GlobalId=chance.local.//8, BranchQual=] errorCode=XAER_RMERR javax.transaction.xa.XAException: [Microsoft][SQLServer 2000 Driver for JDBC][SQLServer]xa_start (0) returns -8 at com.microsoft.jdbcx.sqlserver.SQLServerImplXAResource.executeXaRpc(Unknown Source) at com.microsoft.jdbcx.sqlserver.SQLServerImplXAResource.start(Unknown Source) at com.microsoft.jdbcx.base.BaseXAResource.start(Unknown Source) at org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.start(XAManagedConnection.java:110) at org.jboss.tm.TransactionImpl.startResource(TransactionImpl.java:1137) at org.jboss.tm.TransactionImpl.enlistResource(TransactionImpl.java:624) at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:461) at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:359) at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:546) at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:837) at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:102) at com.solarmetric.kodo.impl.jdbc.runtime.DataSourceConnector.getConnection(DataSourceConnector.java:61) at com.solarmetric.kodo.impl.jdbc.schema.DBDictionaryFactory.getDictionary(DBDictionaryFactory.java:179) at com.solarmetric.kodo.impl.jdbc.JDBCSimpleConfiguration.getDictionary(JDBCSimpleConfiguration.java:336) at com.solarmetric.kodo.impl.jdbc.JDBCPersistenceManagerFactory.registerClassInternal(JDBCPersistenceManagerFactory.java:454) at com.solarmetric.kodo.impl.jdbc.JDBCPersistenceManagerFactory.registerClass(JDBCPersistenceManagerFactory.java:337) at com.solarmetric.kodo.impl.jdbc.RegisterListener.registerClass(RegisterListener.java:53) at javax.jdo.spi.JDOImplHelper.registerClass(JDOImplHelper.java:269) at com.solarmetric.kodo.runtime.AllFieldTypesTest.(AllFieldTypesTest.java) at XAEnvironmentTest.testXATransaction(XAEnvironmentTest.java:99) at XAEnvironmentTest.testXATransaction(XAEnvironmentTest.java:72) at XAEnvironmentTest.start(XAEnvironmentTest.java:323) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:966) at $Proxy11.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:392) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) at $Proxy5.start(Unknown Source) at org.jboss.deployment.SARDeployer.start(SARDeployer.java:231) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:827) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:639) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:612) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.cap
[JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 24-February-2003
JBoss daily test results SUMMARY Number of tests run: 1049 Successful tests: 1045 Errors:1 Failures: 3 [time of test: 2003-02-24.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-24.12-05 for details of this test. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS Suite: MissingClassUnitTestCase Test: testDeployServiceWithoutClass(org.jboss.test.jmx.test.MissingClassUnitTestCase) Type:error Exception: org.jboss.deployment.DeploymentException Message: jboss.test:name=missingclasstest is not registered.; - nested throwable: (javax.management.InstanceNotFoundException: jboss.test:name=missingclasstest is not registered.) - Suite: SecurityUnitTestCase Test:testSecureHttpInvoker(org.jboss.test.naming.test.SecurityUnitTestCase) Type:failure Exception: junit.framework.AssertionFailedError Message: Should not have been able to lookup(invokers) - Suite: SecurityUnitTestCase Test: testSecureHttpInvokerFailure(org.jboss.test.naming.test.SecurityUnitTestCase) Type:failure Exception: junit.framework.AssertionFailedError Message: Should not have been able to lookup(invokers) - Suite: BeanStressTestCase Test:testDeadLockFromClient(org.jboss.test.deadlock.test.BeanStressTestCase) Type:failure Exception: junit.framework.AssertionFailedError Message: expected a client deadlock for AB BA - --- 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
On 2003.02.24 15:16 Igor Fedorenko wrote: > David, > > Can you remind me how you are going to deal with possible loops in > transaction tree. > > Consider this scenario: node A starts a transaction, does some work and > calls node B. Node B does some more work and calls node A back. There is > no way node B can know if the transaction has visited node A or not, and > if I understood your design correctly node B will enlist node A into the > transaction and create a loop. yes. I don't really see any alternative. B has to send A some indication of what transaction the work should be done in, and A has to be able to send back some indication that the work failed, tx is marked for rollback. Of course, this is no big deal, all you > have to do is to write TransactionImpl to re-entrant and make sure that > TransactionImpl.prepare returns "read-only" if the transaction is already > being prepared. I guess one part of this is that the tx import should recognize if there is already a branch of the tx on the machine, and use the original import/original tx. I'll have to review to see if this is what happens. Thanks david > > Thanks in advance. > > > > > -Original Message- > > From: David Jencks [mailto:[EMAIL PROTECTED] > > Sent: Monday, February 24, 2003 2:11 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] TxInterceptor split is still the best thing > > since sliced bread > > > > > > 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 > > remember the reasons for my design decisions for more than > > about 5 minutes. > > I've written fairly detailed explanations of my views of > > both interceptor > > architecture and corba integration and asked for comments or > > whether you > > agree or disagree. I haven't seen any direct responses. > > > > At this point I don't want to read the same argument from you again. > > Please implement your idea for how dtm will work so we can discuss > > something concrete. > > > > thanks > > david > > > > > > On 2003.02.24 13:37 Bill Burke wrote: > > > Sure. The TxSupport class is a nice change and makes the > > code much more > > > readable. I have stated this before. But > > > > > > Merge TxSupport.clientInvoke and serverInvoke into one > > method. Remove > > > all > > > logic from client interceptor except TX propagation. > > Propagate the TX > > > always. Again, my reasoning is to isolate the EJB > > container from the > > > transport mechanism. Currently, in 3.2, you can invoke on > > an EJB from > > > any > > > protocol at the same time. With David's change, non-Java > > clients that > > > support TX propagation would require that > > TxSupport.clientInvoke be run > > > on > > > the server thus requiring us to have transport specific server-sdie > > > interceptor chains and a change to the current > > architecture. I think > > > that > > > this creates further complication in the server-side > > architecture and > > > will > > > further bloat configuration. All just to save a tx propagation for > > > NotSupported and RequiresNew methods. > > > > > > Or are you talking about the AOP stuff? Well, it is > > implemented, I do > > > have > > > an API. I have written the AOP Tx interceptor and it is > > tested within > > > the > > > testsuite. I am working on the Security one. So far, my > > design seems to > > > fit. The real test will be with the persistence metadata > > since this is > > > much more complicated. I've made an attempt to explain my > > design with > > > the > > > bootcamp slides and the crappy documentation I put together on the > > > website > > > /developers/projects/jboss/aop.jsp. > > > > > > > > > Bill > > > > > > > -Original Message- > > > > From: [EMAIL PROTECTED] > > > > [mailto:[EMAIL PROTECTED] > > Behalf Of Dain > > > > Sundstrom > > > > Sent: Monday, February 24, 2003 12:36 PM > > > > To: [EMAIL PROTECTED] > > > > Subject: Re: [JBoss-dev] TxInterceptor split is still the > > best thing > > > > since sliced bread > > > > > > > > > > > > Bill, > > > > > > > > Where is you design? David's design looks totally > > obvious to me. It > > > > is well understood, and based on our existing > > "real-world" experiences. > > > > To me it looks like you are the one invent "the perfect > > design/API". > > > > So can you present you invocation chain as did and show > > us the error in > > > > our logic? > > > > > > > > -dain > > > > > > > > On Monday, February 24, 2003, at 09:39 AM, Bill Burke wrote: > > > > > > > > > > > > > > > > > > >> -Original Message- > > > > >> From: [EMAIL PROTECTED] > > > > >> > > [mailto:[EMAIL PROTECTED] Behalf Of > > > > >> David > > > > >> Jencks > > > > >> Sent: Saturday, February 22, 2003 11:48 AM > > > > >> To: [EMAIL PROTECTED] > > > > >> Subject: RE: [JBoss-dev] TxInterceptor split is still > > the best thing > >
RE: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread
David, Can you remind me how you are going to deal with possible loops in transaction tree. Consider this scenario: node A starts a transaction, does some work and calls node B. Node B does some more work and calls node A back. There is no way node B can know if the transaction has visited node A or not, and if I understood your design correctly node B will enlist node A into the transaction and create a loop. Of course, this is no big deal, all you have to do is to write TransactionImpl to re-entrant and make sure that TransactionImpl.prepare returns "read-only" if the transaction is already being prepared. Thanks in advance. > -Original Message- > From: David Jencks [mailto:[EMAIL PROTECTED] > Sent: Monday, February 24, 2003 2:11 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] TxInterceptor split is still the best thing > since sliced bread > > > 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 > remember the reasons for my design decisions for more than > about 5 minutes. > I've written fairly detailed explanations of my views of > both interceptor > architecture and corba integration and asked for comments or > whether you > agree or disagree. I haven't seen any direct responses. > > At this point I don't want to read the same argument from you again. > Please implement your idea for how dtm will work so we can discuss > something concrete. > > thanks > david > > > On 2003.02.24 13:37 Bill Burke wrote: > > Sure. The TxSupport class is a nice change and makes the > code much more > > readable. I have stated this before. But > > > > Merge TxSupport.clientInvoke and serverInvoke into one > method. Remove > > all > > logic from client interceptor except TX propagation. > Propagate the TX > > always. Again, my reasoning is to isolate the EJB > container from the > > transport mechanism. Currently, in 3.2, you can invoke on > an EJB from > > any > > protocol at the same time. With David's change, non-Java > clients that > > support TX propagation would require that > TxSupport.clientInvoke be run > > on > > the server thus requiring us to have transport specific server-sdie > > interceptor chains and a change to the current > architecture. I think > > that > > this creates further complication in the server-side > architecture and > > will > > further bloat configuration. All just to save a tx propagation for > > NotSupported and RequiresNew methods. > > > > Or are you talking about the AOP stuff? Well, it is > implemented, I do > > have > > an API. I have written the AOP Tx interceptor and it is > tested within > > the > > testsuite. I am working on the Security one. So far, my > design seems to > > fit. The real test will be with the persistence metadata > since this is > > much more complicated. I've made an attempt to explain my > design with > > the > > bootcamp slides and the crappy documentation I put together on the > > website > > /developers/projects/jboss/aop.jsp. > > > > > > Bill > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] > Behalf Of Dain > > > Sundstrom > > > Sent: Monday, February 24, 2003 12:36 PM > > > To: [EMAIL PROTECTED] > > > Subject: Re: [JBoss-dev] TxInterceptor split is still the > best thing > > > since sliced bread > > > > > > > > > Bill, > > > > > > Where is you design? David's design looks totally > obvious to me. It > > > is well understood, and based on our existing > "real-world" experiences. > > > To me it looks like you are the one invent "the perfect > design/API". > > > So can you present you invocation chain as did and show > us the error in > > > our logic? > > > > > > -dain > > > > > > On Monday, February 24, 2003, at 09:39 AM, Bill Burke wrote: > > > > > > > > > > > > > > >> -Original Message- > > > >> From: [EMAIL PROTECTED] > > > >> > [mailto:[EMAIL PROTECTED] Behalf Of > > > >> David > > > >> Jencks > > > >> Sent: Saturday, February 22, 2003 11:48 AM > > > >> To: [EMAIL PROTECTED] > > > >> Subject: RE: [JBoss-dev] TxInterceptor split is still > the best thing > > > >> since sliced bread > > > >> > > > >> > > > >> This is really boring and unpleasant, bill. We don't seem to > > > > > > > > I am sorry I am boring you. Summarized, my major > concern with the TX > > > > refactor is that it will not work for clients that cannot have > > > > interceptor > > > > chains (i.e. non-Java), but support Tx propagation > (CORBA) for all > > > > trans-attributes (specifically, NotSupported, and > RequiresNew). I > > > > thought > > > > Marc's vision for creating these generic, transport > specific invokers > > > > was to > > > > isolate the EJB Container from the transport layer, and > I see this > > > > refactor > > > > as breaking this vision. > > > > > > > > The only way I see this working is if we have separate >
RE: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread
> > One more thing. This was fine in 2.4 and 3.0 when there was a one to one > mapping between client, transport and EJB Container, but in 3.2 and > higher, > there is a many to one relationship between transport and EJB Container. > So? I just checked standard jboss.xml and all the client interceptor chains depend only on the nature of the object at the top, not the transport mechanism. IMO the transport mechanism should not affect the functionality of the interceptor chain, and the transport mechansim should be completely pluggable. I tend to regard the 2 or 3 chains for clients (home, single bean, and list) as conceptually different chains: certainly if we have method-specific interceptor chains they will be different. So, once more: my idea of a chain is like: ci1 ci2 ... plugable transport layer si1 si2 ... target object. Whatever transport layer you plug in, the interceptors should be the same. This goes for remote, local, corba, whatever. Where the ci's live is a separate question. 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
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. 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 occurs to me that what you write is consistent with not having client side interceptors for aop. Is this your plan? If so, how will you gather the context information for the invocation? If not, why do you want to put limits on what the client side interceptors can do? thanks david > > > remember the reasons for my design decisions for more than about > > 5 minutes. > > I've written fairly detailed explanations of my views of both > interceptor > > architecture and corba integration and asked for comments or whether > you > > agree or disagree. I haven't seen any direct responses. > > > > At this point I don't want to read the same argument from you again. > > Please implement your idea for how dtm will work so we can discuss > > something concrete. > > > > I think I already have (see below), but will reread your posts to make > sure. > > Bill > > > > > thanks > > david > > > > > > On 2003.02.24 13:37 Bill Burke wrote: > > > Sure. The TxSupport class is a nice change and makes the code much > more > > > readable. I have stated this before. But > > > > > > Merge TxSupport.clientInvoke and serverInvoke into one method. > Remove > > > all > > > logic from client interceptor except TX propagation. Propagate the > TX > > > always. Again, my reasoning is to isolate the EJB container from > the > > > transport mechanism. Currently, in 3.2, you can invoke on an EJB > from > > > any > > > protocol at the same time. With David's change, non-Java clients > that > > > support TX propagation would require that TxSupport.clientInvoke be > run > > > on > > > the server thus requiring us to have transport specific server-sdie > > > interceptor chains and a change to the current architecture. I think > > > that > > > this creates further complication in the server-side architecture and > > > will > > > further bloat configuration. All just to save a tx propagation for > > > NotSupported and RequiresNew methods. > > > > > > Or are you talking about the AOP stuff? Well, it is implemented, I > do > > > have > > > an API. I have written the AOP Tx interceptor and it is tested > within > > > the > > > testsuite. I am working on the S
RE: [JBoss-dev] org.jboss.aop.MethodMetaData
> Aha! At least there's something we can agree on! I may be too dense in my understanding of the TX stuff right now so have patience. I may/may not have a point. > > > > As far as remoting goes. The SimpleMetaData class does have the means > > now > > to define whether data should be serialized across the wire. My thought > > is > > that when a DP (and later an AOP'ized Class") is serialized, my thoughts > > are > > that the the serializer will again walk through the chain and ask each > > repository for its serializable data. Or another possibility > is that the > > Interceptor knows which metadata should be serialized. This area needs > > some > > thought and iteration. > > At the moment I'd think that having a single level metadata repository and > having the items you store in it know how and if to serialize themselves > would make sense. Or using non-string keys that indicate if the value is > transient is another possibility. > SimpleMetaData does have this capability. Its supposed to encapsulate all the different kinds of payloads that are in the old Invocation object. 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 still the best thing since sliced bread
> > > > > > > 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" > One more thing. This was fine in 2.4 and 3.0 when there was a one to one mapping between client, transport and EJB Container, but in 3.2 and higher, there is a many to one relationship between transport and EJB Container. > 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. > > > remember the reasons for my design decisions for more than about > > 5 minutes. > > I've written fairly detailed explanations of my views of both > interceptor > > architecture and corba integration and asked for comments or whether you > > agree or disagree. I haven't seen any direct responses. > > > > At this point I don't want to read the same argument from you again. > > Please implement your idea for how dtm will work so we can discuss > > something concrete. > > > > I think I already have (see below), but will reread your posts to > make sure. > > Bill > > > > > thanks > > david > > > > > > On 2003.02.24 13:37 Bill Burke wrote: > > > Sure. The TxSupport class is a nice change and makes the > code much more > > > readable. I have stated this before. But > > > > > > Merge TxSupport.clientInvoke and serverInvoke into one method. Remove > > > all > > > logic from client interceptor except TX propagation. Propagate the TX > > > always. Again, my reasoning is to isolate the EJB container from the > > > transport mechanism. Currently, in 3.2, you can invoke on an EJB from > > > any > > > protocol at the same time. With David's change, non-Java clients that > > > support TX propagation would require that > TxSupport.clientInvoke be run > > > on > > > the server thus requiring us to have transport specific server-sdie > > > interceptor chains and a change to the current architecture. I think > > > that > > > this creates further complication in the server-side architecture and > > > will > > > further bloat configuration. All just to save a tx propagation for > > > NotSupported and RequiresNew methods. > > > > > > Or are you talking about the AOP stuff? Well, it is implemented, I do > > > have > > > an API. I have written the AOP Tx interceptor and it is tested within > > > the > > > testsuite. I am working on the Security one. So far, my > > design seems to > > > fit. The real test will be with the persistence metadata > since this is > > > much more complicated. I've made an attempt to explain my design with > > > the > > > bootcamp slides and the crappy documentation I put together on the > > > website > > > /developers/projects/jboss/aop.jsp. > > > > > > > > > Bill > > > > > > > -Original Message- > > > > From: [EMAIL PROTECTED] > > > > [mailto:[EMAIL PROTECTED] > > Behalf Of Dain > > > > Sundstrom > > > > Sent: Monday, February 24, 2003 12:36 PM > > > > To: [EMAIL PROTECTED] > > > > Subject: Re: [JBoss-dev] TxInterceptor split is still the best thing > > > > since sliced bread > > > > > > > > > > > > Bill, > > > > > > > > Where is you design? David's design looks totally obvious > to me. It > > > > is well understood, and based on our existing "real-world" > > experiences. > > > > To me it looks like you are the one invent "the perfect > design/API". > > > > So can you present you invocation chain as did and show us > > the error in > > > > our logic? > > > > > > > > -dain > > > > > > > > On Monday, February 24, 2003, at 09:39 AM, Bill Burke wrote: > > > > > > > > > > > > > > > > > > >> -Original Message- > > > > >> From: [EMAIL PROTECTED] > > > > >> [mailto:[EMAIL PROTECTED] > Behalf Of > > > > >> David > > > > >> Jencks > > > > >> Sent: Saturday, February 22, 2003 11:48 AM > > > > >> To: [EMAIL PROTECTED] > > > > >> Subject: RE: [JBoss-dev] TxInterceptor split is still the > > best thing > > > > >> since sliced bread > > > > >> > > > > >> > > > > >> This is really boring and unpleasant, bill. We don't seem to > > > > > > > > > > I am sorry I am boring you. Summarized, my major concern > > with the TX > > > > > refactor is that it will not work for clients that cannot have > > > > > interceptor > > > > > chains (i.e. non-Java), but support Tx propagation (CORBA) for all > > > > > trans-attributes (specifical
RE: [JBoss-dev] org.jboss.aop.MethodMetaData
On 2003.02.24 14:25 Bill Burke wrote: > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Behalf Of > David > > Jencks > > Sent: Monday, February 24, 2003 1:54 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] org.jboss.aop.MethodMetaData > > > > > > On 2003.02.24 13:17 Bill Burke wrote: > > > > > > > > > > -Original Message- > > > > From: [EMAIL PROTECTED] > > > > [mailto:[EMAIL PROTECTED] Behalf Of > > > David > > > > Jencks > > > > Sent: Monday, February 24, 2003 10:37 AM > > > > To: [EMAIL PROTECTED] > > > > Subject: RE: [JBoss-dev] org.jboss.aop.MethodMetaData > > > > > > > > > > > > > > > > > > > > > I also want to add that the current interface for Metadata, > metadata > > > > > chains, > > > > > and how you configure metadata is open for debate. It probably > is > > > not a > > > > > complete definition and I'm open for suggestions. I'm > > hoping that as > > > I > > > > > port > > > > > some of the current interceptors more requirements will be > flushed > > > out. > > > > > Persistence will be the big test. > > > > > > > > I don't have any very solid ideas yet, but I think these would be > > > > improvements: > > > > > > > > 1. Single level lookups with Object keys rather than String: Object > > > > getMetadata(Object key). Why force the guy storing the > > metadata to use > > > a > > > > concealed hashmap with String keys? > > > > > > > > > > Why? Simplicity. But fair nuff. > > > > > > > 2. Put the default metadata in the thing that supplies the chain of > > > > interceptors (Advisor?), and always add it first to what the > > Invocation > > > > gets. (rather than putting the default metadata in the Invocation > > > > directly. > > > > > > > > > > Advisor does not work the way you describe it. The Advisor creates > an > > > ArrayList of MetaData repositories(the chain) and passes it as a > > > parameter > > > to the Invocation object. The Invocation object is itself a > > > MetadataResolver and is first in the chain. > > > > Can you explain why the invocation object has this unique metadata > object > > rather than always getting it from the advisor? Is this how you want > to > > support customization of individual invocations? But where does the > > invocation come from? How will it get this unique metadata? > > > > Invocation object has unique metadata for tx and security propagation for > example. If there is no txid or security credentials to pass, this > object > is empty. Think of it as the payload in the old invocation object. The > Invocation object has unique metadata so that interceptors can pass on > information farther along the chain. > > This is not how I will support customization of individual invocations. > I > have a ThreadMetaData object that is second in the chain. ThreadMetaData > class simply uses a ThreadLocal to hold SimpleMetaData. > > So the chain looks like this currently: > > Invocation, ThreadMetaData, InstanceAdvisor.metadata, > ClassAdvisor.MethodMetaData, ClassAdvisor.defaultmetadata. Aha! At least there's something we can agree on! I like this, now I understand, good idea, etc. etc. Thanks. I missed this reading the code. > > As far as remoting goes. The SimpleMetaData class does have the means > now > to define whether data should be serialized across the wire. My thought > is > that when a DP (and later an AOP'ized Class") is serialized, my thoughts > are > that the the serializer will again walk through the chain and ask each > repository for its serializable data. Or another possibility is that the > Interceptor knows which metadata should be serialized. This area needs > some > thought and iteration. At the moment I'd think that having a single level metadata repository and having the items you store in it know how and if to serialize themselves would make sense. Or using non-string keys that indicate if the value is transient is another possibility. > > Am I making sense? If not, I'll elaborate. > > > I'd think that giving the "top of the chain" object the default > metadata > > and then providing some facility for pulling more in from the > environment > > would make sense. > > > > This is exactly what I do and what I provide. The Class Advisor is > responsible for knowing the chain and providing it to the Invocation > object. > Do you mean something different? No, I didn't quite understand what all the Metadata objects were and where they come from. > > > My impression is that your Advisor object is the top of the interceptor > > chain. Is thie correct or wrong? > > > > > > > Yup. ClassAdvisor is currently top and bottom of chain. > > > The Invocation object does > > > not > > > have amashed down, merged set of metadata. > > > > I didn't say it should. But for sure it should conceal how it looks up > the > > metadata from the guys who are asking for it. > > > > I do this concealing through the MetadataResolver interface. Yes. Thanks david > > Bill >
RE: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread
> > 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. > remember the reasons for my design decisions for more than about > 5 minutes. > I've written fairly detailed explanations of my views of both interceptor > architecture and corba integration and asked for comments or whether you > agree or disagree. I haven't seen any direct responses. > > At this point I don't want to read the same argument from you again. > Please implement your idea for how dtm will work so we can discuss > something concrete. > I think I already have (see below), but will reread your posts to make sure. Bill > thanks > david > > > On 2003.02.24 13:37 Bill Burke wrote: > > Sure. The TxSupport class is a nice change and makes the code much more > > readable. I have stated this before. But > > > > Merge TxSupport.clientInvoke and serverInvoke into one method. Remove > > all > > logic from client interceptor except TX propagation. Propagate the TX > > always. Again, my reasoning is to isolate the EJB container from the > > transport mechanism. Currently, in 3.2, you can invoke on an EJB from > > any > > protocol at the same time. With David's change, non-Java clients that > > support TX propagation would require that TxSupport.clientInvoke be run > > on > > the server thus requiring us to have transport specific server-sdie > > interceptor chains and a change to the current architecture. I think > > that > > this creates further complication in the server-side architecture and > > will > > further bloat configuration. All just to save a tx propagation for > > NotSupported and RequiresNew methods. > > > > Or are you talking about the AOP stuff? Well, it is implemented, I do > > have > > an API. I have written the AOP Tx interceptor and it is tested within > > the > > testsuite. I am working on the Security one. So far, my > design seems to > > fit. The real test will be with the persistence metadata since this is > > much more complicated. I've made an attempt to explain my design with > > the > > bootcamp slides and the crappy documentation I put together on the > > website > > /developers/projects/jboss/aop.jsp. > > > > > > Bill > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] > Behalf Of Dain > > > Sundstrom > > > Sent: Monday, February 24, 2003 12:36 PM > > > To: [EMAIL PROTECTED] > > > Subject: Re: [JBoss-dev] TxInterceptor split is still the best thing > > > since sliced bread > > > > > > > > > Bill, > > > > > > Where is you design? David's design looks totally obvious to me. It > > > is well understood, and based on our existing "real-world" > experiences. > > > To me it looks like you are the one invent "the perfect design/API". > > > So can you present you invocation chain as did and show us > the error in > > > our logic? > > > > > > -dain > > > > > > On Monday, February 24, 2003, at 09:39 AM, Bill Burke wrote: > > > > > > > > > > > > > > >> -Original Message- > > > >> From: [EMAIL PROTECTED] > > > >> [mailto:[EMAIL PROTECTED] Behalf Of > > > >> David > > > >> Jencks > > > >> Sent: Saturday, February 22, 2003 11:48 AM > > > >> To: [EMAIL PROTECTED] > > > >> Subject: RE: [JBoss-dev] TxInterceptor split is still the > best thing > > > >> since sliced bread > > > >> > > > >> > > > >> This is really boring and unpleasant, bill. We don't seem to > > > > > > > > I am sorry I am boring you. Summarized, my major concern > with the TX > > > > refactor is that it will not work for clients that cannot have > > > > interceptor > > > > chains (i.e. non-Java), but support Tx propagation (CORBA) for all > > > > trans-attributes (specifically, NotSupported, and RequiresNew). I > > > > thought > > > > Marc's vision for creating these generic, transport > specific invokers > > > > was to > > > > isolate the EJB Container from the transport layer, and I see this > > > > refactor > > > > as breaking this vision. > > > > > > > > The only way I see this working is if we have separate > > > > transport-specific > > > > interceptor chains on the server to support non-Java clients. I > > > > wanted to > > > > avoid this because this is
RE: [JBoss-dev] org.jboss.aop.MethodMetaData
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of David > Jencks > Sent: Monday, February 24, 2003 1:54 PM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] org.jboss.aop.MethodMetaData > > > On 2003.02.24 13:17 Bill Burke wrote: > > > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] Behalf Of > > David > > > Jencks > > > Sent: Monday, February 24, 2003 10:37 AM > > > To: [EMAIL PROTECTED] > > > Subject: RE: [JBoss-dev] org.jboss.aop.MethodMetaData > > > > > > > > > > > > > > > > I also want to add that the current interface for Metadata, metadata > > > > chains, > > > > and how you configure metadata is open for debate. It probably is > > not a > > > > complete definition and I'm open for suggestions. I'm > hoping that as > > I > > > > port > > > > some of the current interceptors more requirements will be flushed > > out. > > > > Persistence will be the big test. > > > > > > I don't have any very solid ideas yet, but I think these would be > > > improvements: > > > > > > 1. Single level lookups with Object keys rather than String: Object > > > getMetadata(Object key). Why force the guy storing the > metadata to use > > a > > > concealed hashmap with String keys? > > > > > > > Why? Simplicity. But fair nuff. > > > > > 2. Put the default metadata in the thing that supplies the chain of > > > interceptors (Advisor?), and always add it first to what the > Invocation > > > gets. (rather than putting the default metadata in the Invocation > > > directly. > > > > > > > Advisor does not work the way you describe it. The Advisor creates an > > ArrayList of MetaData repositories(the chain) and passes it as a > > parameter > > to the Invocation object. The Invocation object is itself a > > MetadataResolver and is first in the chain. > > Can you explain why the invocation object has this unique metadata object > rather than always getting it from the advisor? Is this how you want to > support customization of individual invocations? But where does the > invocation come from? How will it get this unique metadata? > Invocation object has unique metadata for tx and security propagation for example. If there is no txid or security credentials to pass, this object is empty. Think of it as the payload in the old invocation object. The Invocation object has unique metadata so that interceptors can pass on information farther along the chain. This is not how I will support customization of individual invocations. I have a ThreadMetaData object that is second in the chain. ThreadMetaData class simply uses a ThreadLocal to hold SimpleMetaData. So the chain looks like this currently: Invocation, ThreadMetaData, InstanceAdvisor.metadata, ClassAdvisor.MethodMetaData, ClassAdvisor.defaultmetadata. As far as remoting goes. The SimpleMetaData class does have the means now to define whether data should be serialized across the wire. My thought is that when a DP (and later an AOP'ized Class") is serialized, my thoughts are that the the serializer will again walk through the chain and ask each repository for its serializable data. Or another possibility is that the Interceptor knows which metadata should be serialized. This area needs some thought and iteration. Am I making sense? If not, I'll elaborate. > I'd think that giving the "top of the chain" object the default metadata > and then providing some facility for pulling more in from the environment > would make sense. > This is exactly what I do and what I provide. The Class Advisor is responsible for knowing the chain and providing it to the Invocation object. Do you mean something different? > My impression is that your Advisor object is the top of the interceptor > chain. Is thie correct or wrong? > > Yup. ClassAdvisor is currently top and bottom of chain. > The Invocation object does > > not > > have amashed down, merged set of metadata. > > I didn't say it should. But for sure it should conceal how it looks up the > metadata from the guys who are asking for it. > I do this concealing through the MetadataResolver interface. 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 still the best thing since sliced bread
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 remember the reasons for my design decisions for more than about 5 minutes. I've written fairly detailed explanations of my views of both interceptor architecture and corba integration and asked for comments or whether you agree or disagree. I haven't seen any direct responses. At this point I don't want to read the same argument from you again. Please implement your idea for how dtm will work so we can discuss something concrete. thanks david On 2003.02.24 13:37 Bill Burke wrote: > Sure. The TxSupport class is a nice change and makes the code much more > readable. I have stated this before. But > > Merge TxSupport.clientInvoke and serverInvoke into one method. Remove > all > logic from client interceptor except TX propagation. Propagate the TX > always. Again, my reasoning is to isolate the EJB container from the > transport mechanism. Currently, in 3.2, you can invoke on an EJB from > any > protocol at the same time. With David's change, non-Java clients that > support TX propagation would require that TxSupport.clientInvoke be run > on > the server thus requiring us to have transport specific server-sdie > interceptor chains and a change to the current architecture. I think > that > this creates further complication in the server-side architecture and > will > further bloat configuration. All just to save a tx propagation for > NotSupported and RequiresNew methods. > > Or are you talking about the AOP stuff? Well, it is implemented, I do > have > an API. I have written the AOP Tx interceptor and it is tested within > the > testsuite. I am working on the Security one. So far, my design seems to > fit. The real test will be with the persistence metadata since this is > much more complicated. I've made an attempt to explain my design with > the > bootcamp slides and the crappy documentation I put together on the > website > /developers/projects/jboss/aop.jsp. > > > Bill > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Behalf Of Dain > > Sundstrom > > Sent: Monday, February 24, 2003 12:36 PM > > To: [EMAIL PROTECTED] > > Subject: Re: [JBoss-dev] TxInterceptor split is still the best thing > > since sliced bread > > > > > > Bill, > > > > Where is you design? David's design looks totally obvious to me. It > > is well understood, and based on our existing "real-world" experiences. > > To me it looks like you are the one invent "the perfect design/API". > > So can you present you invocation chain as did and show us the error in > > our logic? > > > > -dain > > > > On Monday, February 24, 2003, at 09:39 AM, Bill Burke wrote: > > > > > > > > > > >> -Original Message- > > >> From: [EMAIL PROTECTED] > > >> [mailto:[EMAIL PROTECTED] Behalf Of > > >> David > > >> Jencks > > >> Sent: Saturday, February 22, 2003 11:48 AM > > >> To: [EMAIL PROTECTED] > > >> Subject: RE: [JBoss-dev] TxInterceptor split is still the best thing > > >> since sliced bread > > >> > > >> > > >> This is really boring and unpleasant, bill. We don't seem to > > > > > > I am sorry I am boring you. Summarized, my major concern with the TX > > > refactor is that it will not work for clients that cannot have > > > interceptor > > > chains (i.e. non-Java), but support Tx propagation (CORBA) for all > > > trans-attributes (specifically, NotSupported, and RequiresNew). I > > > thought > > > Marc's vision for creating these generic, transport specific invokers > > > was to > > > isolate the EJB Container from the transport layer, and I see this > > > refactor > > > as breaking this vision. > > > > > > The only way I see this working is if we have separate > > > transport-specific > > > interceptor chains on the server to support non-Java clients. I > > > wanted to > > > avoid this because this is what has happened when I put in support > for > > > multiple invokers. Client-side interceptor configuration became > > > bloated. > > > All this to avoid creating and passing over a TxId. See my point > now? > > > > > > === > > > > > > As far as AOP goes, I'm hoping that as we implement services on top > of > > > the > > > Framework and apply the framework to JMX and remoting, the > > > requirements and > > > API will be fleshed out as we iterate. I'd like the design of AOP to > > > be > > > driven by "real-world" requirements and applications rather than what > > > we > > > might think as the perfect (and probably bloated) design/API might be > > > currently. I'm not afraid of throwing code out or having to modify > > > huge > > > amounts of code to iterate. Iteration is key. Allows us to get to > > > market > > > quick and to quickly notice bad designs. Didn't somebody say > "Release > > > early, release often"? > > > > > > Bill > > > > > > > > >> have a shared > > >> understanding of how inte
RE: [JBoss-dev] org.jboss.aop.MethodMetaData
On 2003.02.24 13:17 Bill Burke wrote: > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Behalf Of > David > > Jencks > > Sent: Monday, February 24, 2003 10:37 AM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] org.jboss.aop.MethodMetaData > > > > > > > > > > > I also want to add that the current interface for Metadata, metadata > > > chains, > > > and how you configure metadata is open for debate. It probably is > not a > > > complete definition and I'm open for suggestions. I'm hoping that as > I > > > port > > > some of the current interceptors more requirements will be flushed > out. > > > Persistence will be the big test. > > > > I don't have any very solid ideas yet, but I think these would be > > improvements: > > > > 1. Single level lookups with Object keys rather than String: Object > > getMetadata(Object key). Why force the guy storing the metadata to use > a > > concealed hashmap with String keys? > > > > Why? Simplicity. But fair nuff. > > > 2. Put the default metadata in the thing that supplies the chain of > > interceptors (Advisor?), and always add it first to what the Invocation > > gets. (rather than putting the default metadata in the Invocation > > directly. > > > > Advisor does not work the way you describe it. The Advisor creates an > ArrayList of MetaData repositories(the chain) and passes it as a > parameter > to the Invocation object. The Invocation object is itself a > MetadataResolver and is first in the chain. Can you explain why the invocation object has this unique metadata object rather than always getting it from the advisor? Is this how you want to support customization of individual invocations? But where does the invocation come from? How will it get this unique metadata? I'd think that giving the "top of the chain" object the default metadata and then providing some facility for pulling more in from the environment would make sense. My impression is that your Advisor object is the top of the interceptor chain. Is thie correct or wrong? The Invocation object does > not > have amashed down, merged set of metadata. I didn't say it should. But for sure it should conceal how it looks up the metadata from the guys who are asking for it. The Invocation only has a > reference to the repositories not a copy of each metadata element. I > don't > know if this is a good analogy, but I think of it as polymorphic data. > > > I have some code with these ideas, I'll try to commit it or send > > it to you > > later today. > > > > I think it will take some experimentation to get something that works > > really well. > > > > I agree. I want this chaining, but am open to the implementation. fine david > > 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
RE: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread
Sure. The TxSupport class is a nice change and makes the code much more readable. I have stated this before. But Merge TxSupport.clientInvoke and serverInvoke into one method. Remove all logic from client interceptor except TX propagation. Propagate the TX always. Again, my reasoning is to isolate the EJB container from the transport mechanism. Currently, in 3.2, you can invoke on an EJB from any protocol at the same time. With David's change, non-Java clients that support TX propagation would require that TxSupport.clientInvoke be run on the server thus requiring us to have transport specific server-sdie interceptor chains and a change to the current architecture. I think that this creates further complication in the server-side architecture and will further bloat configuration. All just to save a tx propagation for NotSupported and RequiresNew methods. Or are you talking about the AOP stuff? Well, it is implemented, I do have an API. I have written the AOP Tx interceptor and it is tested within the testsuite. I am working on the Security one. So far, my design seems to fit. The real test will be with the persistence metadata since this is much more complicated. I've made an attempt to explain my design with the bootcamp slides and the crappy documentation I put together on the website /developers/projects/jboss/aop.jsp. Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Dain > Sundstrom > Sent: Monday, February 24, 2003 12:36 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] TxInterceptor split is still the best thing > since sliced bread > > > Bill, > > Where is you design? David's design looks totally obvious to me. It > is well understood, and based on our existing "real-world" experiences. > To me it looks like you are the one invent "the perfect design/API". > So can you present you invocation chain as did and show us the error in > our logic? > > -dain > > On Monday, February 24, 2003, at 09:39 AM, Bill Burke wrote: > > > > > > >> -Original Message- > >> From: [EMAIL PROTECTED] > >> [mailto:[EMAIL PROTECTED] Behalf Of > >> David > >> Jencks > >> Sent: Saturday, February 22, 2003 11:48 AM > >> To: [EMAIL PROTECTED] > >> Subject: RE: [JBoss-dev] TxInterceptor split is still the best thing > >> since sliced bread > >> > >> > >> This is really boring and unpleasant, bill. We don't seem to > > > > I am sorry I am boring you. Summarized, my major concern with the TX > > refactor is that it will not work for clients that cannot have > > interceptor > > chains (i.e. non-Java), but support Tx propagation (CORBA) for all > > trans-attributes (specifically, NotSupported, and RequiresNew). I > > thought > > Marc's vision for creating these generic, transport specific invokers > > was to > > isolate the EJB Container from the transport layer, and I see this > > refactor > > as breaking this vision. > > > > The only way I see this working is if we have separate > > transport-specific > > interceptor chains on the server to support non-Java clients. I > > wanted to > > avoid this because this is what has happened when I put in support for > > multiple invokers. Client-side interceptor configuration became > > bloated. > > All this to avoid creating and passing over a TxId. See my point now? > > > > === > > > > As far as AOP goes, I'm hoping that as we implement services on top of > > the > > Framework and apply the framework to JMX and remoting, the > > requirements and > > API will be fleshed out as we iterate. I'd like the design of AOP to > > be > > driven by "real-world" requirements and applications rather than what > > we > > might think as the perfect (and probably bloated) design/API might be > > currently. I'm not afraid of throwing code out or having to modify > > huge > > amounts of code to iterate. Iteration is key. Allows us to get to > > market > > quick and to quickly notice bad designs. Didn't somebody say "Release > > early, release often"? > > > > Bill > > > > > >> have a shared > >> understanding of how interceptors ought to work with local and remote > >> calls. Most of your comments make no sense to me, and I think > >> contrariwise. I'll try to explain my view one more time, and > >> I'll write an > >> interceptor framework that satisfies my understanding of what is > >> needed for > >> mbeans, ejbs, remoting, and aop (which I don't understand all that > >> well). > >> If you don't like it and I can't understand your objections, I'll let > >> you > >> indulge your previously expressed wish to write a transaction > >> manager. You > >> might also get that wish fulfilled if you say the following is > >> obvious. I > >> thought it was, but I don't think we have agreed on it. I'm writing > >> it > >> down to try to form a basis for discussion, which is currently > >> missing. > >> > >> == > >> > >> Dave's mental model for invocations. > >> > >
[JBoss-dev] [ jboss-Bugs-692398 ] CachedConnectionManager.unregisterConnection
Bugs item #692398, was opened at 2003-02-24 12:40 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=692398&group_id=22866 Category: JBossServer Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Paul W. Ward (pward) Assigned to: Nobody/Anonymous (nobody) Summary: CachedConnectionManager.unregisterConnection Initial Comment: CachedConnectionManager.unregisterConnection throws an IllegalStateException when the connection being unregistered is not the first connection in the map. The throw of "Trying to return an unknown connection2!" should be moved to after the for loop it's currently sitting in. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=692398&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] org.jboss.aop.MethodMetaData
One more thing We really need a way to generically define metadata and a generic way for an interceptor to obtain class/ejb metadata. Currently, if somebody wants to define a custom interceptor, the only way define class/ejb metadata is to modify and recompile JBoss code. Interceptors should be deployable components. The way I have currently designed the AOP framework, this is possible. It may need some tweaking here and there, but I think the design fits. Bill > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of David > Jencks > Sent: Monday, February 24, 2003 10:37 AM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] org.jboss.aop.MethodMetaData > > > > > > I also want to add that the current interface for Metadata, metadata > > chains, > > and how you configure metadata is open for debate. It probably is not a > > complete definition and I'm open for suggestions. I'm hoping that as I > > port > > some of the current interceptors more requirements will be flushed out. > > Persistence will be the big test. > > I don't have any very solid ideas yet, but I think these would be > improvements: > > 1. Single level lookups with Object keys rather than String: Object > getMetadata(Object key). Why force the guy storing the metadata to use a > concealed hashmap with String keys? > > 2. Put the default metadata in the thing that supplies the chain of > interceptors (Advisor?), and always add it first to what the Invocation > gets. (rather than putting the default metadata in the Invocation > directly. > > I have some code with these ideas, I'll try to commit it or send > it to you > later today. > > I think it will take some experimentation to get something that works > really well. > > david > > > > > 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 --- 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] org.jboss.aop.MethodMetaData
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Sacha > Labourey > Sent: Monday, February 24, 2003 10:33 AM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] org.jboss.aop.MethodMetaData > > > > When an > > Interceptor wants metadata, it walks the chain. Each > > repository decides > > whether or not it can resolve the metadata, or how to resolve > > the metadata > > reference based on the context of the Invocation. For example, for > > MethodMetaData, the context of the Invocation is the method > > name. My main > > goal here it to: > > > > 1) Allow metadata to be programmitcally overriden generically > > at runtime > > > > 2) Allow default metadata to be defined within an > > application, JVM, and also > > cluster-wide. > > And I really love that. Though I don't think it is the role of the > interceptor to iterate over the Repositories but instead to some other > component (such as the repository itself) to delegate the > resolution down to > the chain. It makes me think to the exact opposite of the Clasloader > mechanism: try to load locally and if not present, ask parent > (i.e. Servlet > mode) > > I disagree. The MetadataRepository should not have a concept of a parent. Think of it this way. You hava Class metadata that applies to multiple classes. One Class is configured to belong to one Cluster partition, a different class belongs to another. Is that a good enough use case? The invocation object receives the chain of references to the repositories as an Arraylist. The interceptor asks the invocation object to resolve the metadata for it. 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] org.jboss.aop.MethodMetaData
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of David > Jencks > Sent: Monday, February 24, 2003 10:37 AM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] org.jboss.aop.MethodMetaData > > > > > > I also want to add that the current interface for Metadata, metadata > > chains, > > and how you configure metadata is open for debate. It probably is not a > > complete definition and I'm open for suggestions. I'm hoping that as I > > port > > some of the current interceptors more requirements will be flushed out. > > Persistence will be the big test. > > I don't have any very solid ideas yet, but I think these would be > improvements: > > 1. Single level lookups with Object keys rather than String: Object > getMetadata(Object key). Why force the guy storing the metadata to use a > concealed hashmap with String keys? > Why? Simplicity. But fair nuff. > 2. Put the default metadata in the thing that supplies the chain of > interceptors (Advisor?), and always add it first to what the Invocation > gets. (rather than putting the default metadata in the Invocation > directly. > Advisor does not work the way you describe it. The Advisor creates an ArrayList of MetaData repositories(the chain) and passes it as a parameter to the Invocation object. The Invocation object is itself a MetadataResolver and is first in the chain. The Invocation object does not have amashed down, merged set of metadata. The Invocation only has a reference to the repositories not a copy of each metadata element. I don't know if this is a good analogy, but I think of it as polymorphic data. > I have some code with these ideas, I'll try to commit it or send > it to you > later today. > > I think it will take some experimentation to get something that works > really well. > I agree. I want this chaining, but am open to the implementation. 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[2]: [JBoss-dev] Deployment and XDoclet generation with JBoss-IDE
IF> Thanks for advertising my eclipse deployer, Hans ;-). IF> Actual JBoss-IDE Deployment discussion can be found here IF> http://www.jboss.org/forums/thread.jsp?forum=162&thread=28889 Thanks for the correction (: Hans --- 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] Deployment and XDoclet generation with JBoss-IDE
Thanks for advertising my eclipse deployer, Hans ;-). Actual JBoss-IDE Deployment discussion can be found here http://www.jboss.org/forums/thread.jsp?forum=162&thread=28889 > -Original Message- > From: Hans Dockter [mailto:[EMAIL PROTECTED] > Sent: Monday, February 24, 2003 12:11 PM > To: [EMAIL PROTECTED] > Subject: [JBoss-dev] Deployment and XDoclet generation with JBoss-IDE > > > Hi all, > > I've started two threads in the forum to present and discuss ideas > about deployment and XDoclet generation with JBoss-IDE. > > Deployment: > http://sourceforge.net/tracker/index.php?func=detail&aid=63914 > 1&group_id=22866&atid=376687 > > XDoclet generation: > http://www.jboss.org/forums/thread.jsp?forum=162&thread=28867 > > Having these features implemented will be a quantum leap for JBoss > development. > > Hans > > > > --- > 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
Bill, Where is you design? David's design looks totally obvious to me. It is well understood, and based on our existing "real-world" experiences. To me it looks like you are the one invent "the perfect design/API". So can you present you invocation chain as did and show us the error in our logic? -dain On Monday, February 24, 2003, at 09:39 AM, Bill Burke wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David Jencks Sent: Saturday, February 22, 2003 11:48 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread This is really boring and unpleasant, bill. We don't seem to I am sorry I am boring you. Summarized, my major concern with the TX refactor is that it will not work for clients that cannot have interceptor chains (i.e. non-Java), but support Tx propagation (CORBA) for all trans-attributes (specifically, NotSupported, and RequiresNew). I thought Marc's vision for creating these generic, transport specific invokers was to isolate the EJB Container from the transport layer, and I see this refactor as breaking this vision. The only way I see this working is if we have separate transport-specific interceptor chains on the server to support non-Java clients. I wanted to avoid this because this is what has happened when I put in support for multiple invokers. Client-side interceptor configuration became bloated. All this to avoid creating and passing over a TxId. See my point now? === As far as AOP goes, I'm hoping that as we implement services on top of the Framework and apply the framework to JMX and remoting, the requirements and API will be fleshed out as we iterate. I'd like the design of AOP to be driven by "real-world" requirements and applications rather than what we might think as the perfect (and probably bloated) design/API might be currently. I'm not afraid of throwing code out or having to modify huge amounts of code to iterate. Iteration is key. Allows us to get to market quick and to quickly notice bad designs. Didn't somebody say "Release early, release often"? Bill have a shared understanding of how interceptors ought to work with local and remote calls. Most of your comments make no sense to me, and I think contrariwise. I'll try to explain my view one more time, and I'll write an interceptor framework that satisfies my understanding of what is needed for mbeans, ejbs, remoting, and aop (which I don't understand all that well). If you don't like it and I can't understand your objections, I'll let you indulge your previously expressed wish to write a transaction manager. You might also get that wish fulfilled if you say the following is obvious. I thought it was, but I don't think we have agreed on it. I'm writing it down to try to form a basis for discussion, which is currently missing. == Dave's mental model for invocations. Lets assume first you already have something representing the object you are interested in (such as an ejb Remote interface object, mbean thingy, aop-ized object, or some kind of proxy). Items marked with a * might be removed for non-remotable objects. Key to symbols: \/ interceptor chain "invokeNext()" calls. \/ || method/field access/... calls whose nature may vary depending on the application and that are not part of the interceptor/invocation framework. \/ \/ calls between "segments". These are of the form invoke(invocation) on a particular object found by the current interceptor. .. sequence of interceptors in a chain. || || transport mechanism. For a remote object, this is the boundary between client and server. === Some program does something on the "object" \/ || The Object \/ || Something that knows about interceptor chains and metadata. It looks at the method (or field access, ...) call and its environment and determines what interceptor chain to use. It constructs an Invocation object that includes an iterator over the selected chain, the method call data, and some metadata. Then it starts the invocation down the chain. I will call this a Container. I believe it corresponds to your aop Advisor(s). \/ Several interceptors (client side interceptors specific to the object/class you are calling) . \/ * Transport selector interceptor. This examines the metadata and picks a transport endpoint. It calls invoke(invocation) on the selected transport endpoint. It does not call invocation.invokeNext(), so this may be the end of the use of the original interceptor iterator. \/ \/ * Transport endpoint. If this is a local "do nothing" transport, it may simply call invocation.invokeNext(). Otherwise, it replaces the interceptor iterator with one for the client side transport interceptor stack. \/ * Several interceptors (client side in
[JBoss-dev] [ jboss-Bugs-692344 ] CMR relation looks in wrong database
Bugs item #692344, was opened at 2003-02-24 18:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=692344&group_id=22866 Category: JBossCMP Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Maarten Hazewinkel (terkans) Assigned to: Nobody/Anonymous (nobody) Summary: CMR relation looks in wrong database Initial Comment: I am using JBoss 3.2.0 RC2 on Mac OS X 10.2.4 with JDK 1.4.1 (DP 10). I have left the default Datasource as HypersonicSQL in standardjbosscmp-jdbc.xml Additionally, I have deployed a Postgres 7.2 datasource. I have several CMP Entity beans, among with FlowSchema and Transition, deployed in a single ejb-jar. There is a unidirectional 1-n CMR from FlowSchema to Transition. >From a session bean (also deployed in the same ejb-jar), I am accessing a FlowSchema >bean. This is successful. Then I try to get the Transitions collection from the FlowSchema bean, which fails. Looking at the stack trace, I find that the statement SELECT id FROM transition WHERE (schema_id_fk=1) is being executed against the hypersonic datasource. In the jbosscmp-jdbc file, each entity bean has it's datasource set to the Postgres datasource. The section has been left empty. I have found that if I enter the Postgres datasource in the section, the problem goes away, and the requested Transitions are found and returned correctly. Regards, Maarten Hazewinkel java.sql.SQLException: Table not found: TRANSITION in statement [SELECT id FROM transition WHERE (schema_id_fk=1)] at org.hsqldb.Trace.getError(Unknown Source) at org.hsqldb.Result.(Unknown Source) at org.hsqldb.jdbcConnection.executeHSQL(Unknown Source) at org.hsqldb.jdbcConnection.execute(Unknown Source) at org.hsqldb.jdbcStatement.fetchResult(Unknown Source) at org.hsqldb.jdbcStatement.executeQuery(Unknown Source) at org.hsqldb.jdbcPreparedStatement.executeQuery(Unknown Source) at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeQuery(WrappedPreparedStatement.java:289) at org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadRelationCommand.execute(JDBCLoadRelationCommand.java:101) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.loadRelation(JDBCStoreManager.java:699) at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMRFieldBridge.load(JDBCCMRFieldBridge.java:981) at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMRFieldBridge.getInstanceValue(JDBCCMRFieldBridge.java:584) at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCCMRFieldBridge.getValue(JDBCCMRFieldBridge.java:551) at org.jboss.ejb.plugins.cmp.bridge.EntityBridgeInvocationHandler.invoke(EntityBridgeInvocationHandler.java:124) at org.jboss.proxy.compiler.Runtime.invoke(Runtime.java:59) at com.banctec.efm.workflow.ejb.FlowSchemaBean$Proxy.getTransitions() 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.ejb.EntityContainer$ContainerInterceptor.invoke(EntityContainer.java:1044) at org.jboss.ejb.plugins.cmp.jdbc.JDBCRelationInterceptor.invoke(JDBCRelationInterceptor.java:95) at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invoke(EntitySynchronizationInterceptor.java:303) at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:186) at org.jboss.ejb.plugins.EntityReentranceInterceptor.invoke(EntityReentranceInterceptor.java:91) at org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke(EntityInstanceInterceptor.java:174) at org.jboss.ejb.plugins.EntityLockInterceptor.invoke(EntityLockInterceptor.java:107) at org.jboss.ejb.plugins.EntityCreationInterceptor.invoke(EntityCreationInterceptor.java:69) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:108) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:243) at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:104) at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:130) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:208) at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:154) at org.jboss.ejb.EntityContainer.internalInvoke(EntityContainer.java:483) at org.jboss.ejb.Container.invoke(Container.java:652) at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFactory.java:353) at org.jboss.ejb.plugins.local.EntityProxy.invoke(EntityProxy.java:38) at $Proxy409.getTransitions(Un
[JBoss-dev] Deployment and XDoclet generation with JBoss-IDE
Hi all, I've started two threads in the forum to present and discuss ideas about deployment and XDoclet generation with JBoss-IDE. Deployment: http://sourceforge.net/tracker/index.php?func=detail&aid=639141&group_id=22866&atid=376687 XDoclet generation: http://www.jboss.org/forums/thread.jsp?forum=162&thread=28867 Having these features implemented will be a quantum leap for JBoss development. Hans --- 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
On 2003.02.24 11:22 Sacha Labourey wrote: > Hello David, > > > I tend to regard the functionality in client interceptors as really > > required to make anything work. I agree that chain/invoker > > is excessive. > > I think we need the same client side interceptor stack no > > matter what the > > transport. For java clients, these interceptors will really > > live on the > > client. For non java-clients, they will be somewhere inside > > the server > > side of the transport mechanism. > > My guess is that for non-java client, we will (in almost all cases) not > decide what can be done on the client side. Consequently, it will most > probably be the role of the server side invoker to populate the > Invocation > object with additional "well-known-attributes" that are directly > extracted > from the "context" of this specific transport (and not by some > jbossish-client-interceptor as they won't exist in this case) I think, then, that we agree that the functionality implemented by client-side interceptors is not optional but required. I was proposing for simplicity and flexibility that we always implement this functionality with the same code: for non java clients, we have to run these client side interceptors on the server, and the specific transport will have to provide an environment equivalent to the java client environment so that the "client" interceptors can still work. Since we can't really control which client interceptors people will want to use, I don't think we can hardcode the client interceptor functionality into the transport specific code. 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 > > --- 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 David, > I tend to regard the functionality in client interceptors as really > required to make anything work. I agree that chain/invoker > is excessive. > I think we need the same client side interceptor stack no > matter what the > transport. For java clients, these interceptors will really > live on the > client. For non java-clients, they will be somewhere inside > the server > side of the transport mechanism. My guess is that for non-java client, we will (in almost all cases) not decide what can be done on the client side. Consequently, it will most probably be the role of the server side invoker to populate the Invocation object with additional "well-known-attributes" that are directly extracted from the "context" of this specific transport (and not by some jbossish-client-interceptor as they won't exist in this case) --- 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
On 2003.02.24 10:39 Bill Burke wrote: > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Behalf Of > David > > Jencks > > Sent: Saturday, February 22, 2003 11:48 AM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] TxInterceptor split is still the best thing > > since sliced bread > > > > > > This is really boring and unpleasant, bill. We don't seem to > > I am sorry I am boring you. Summarized, my major concern with the TX > refactor is that it will not work for clients that cannot have > interceptor > chains (i.e. non-Java), but support Tx propagation (CORBA) for all > trans-attributes (specifically, NotSupported, and RequiresNew). I > thought > Marc's vision for creating these generic, transport specific invokers was > to > isolate the EJB Container from the transport layer, and I see this > refactor > as breaking this vision. > > The only way I see this working is if we have separate transport-specific > interceptor chains on the server to support non-Java clients. I wanted > to > avoid this because this is what has happened when I put in support for > multiple invokers. Client-side interceptor configuration became bloated. > All this to avoid creating and passing over a TxId. See my point now? Not quite. I tend to regard the functionality in client interceptors as really required to make anything work. I agree that chain/invoker is excessive. I think we need the same client side interceptor stack no matter what the transport. For java clients, these interceptors will really live on the client. For non java-clients, they will be somewhere inside the server side of the transport mechanism. I also think that the transport layer needs both client and server side interceptors for behavior that is specific to the transport layer. This should allow all "ejb-specific" client side interceptor chains to be independent of the transport layer. Does this seem reasonable? I think making the functionality in client interceptors optional will only lead to confusion and trouble. I'm still interested to know if you have any objections to the model I sketched out. thanks david > > === > > As far as AOP goes, I'm hoping that as we implement services on top of > the > Framework and apply the framework to JMX and remoting, the requirements > and > API will be fleshed out as we iterate. I'd like the design of AOP to be > driven by "real-world" requirements and applications rather than what we > might think as the perfect (and probably bloated) design/API might be > currently. I'm not afraid of throwing code out or having to modify huge > amounts of code to iterate. Iteration is key. Allows us to get to > market > quick and to quickly notice bad designs. Didn't somebody say "Release > early, release often"? > > Bill > > > > have a shared > > understanding of how interceptors ought to work with local and remote > > calls. Most of your comments make no sense to me, and I think > > contrariwise. I'll try to explain my view one more time, and > > I'll write an > > interceptor framework that satisfies my understanding of what is > > needed for > > mbeans, ejbs, remoting, and aop (which I don't understand all that > well). > > If you don't like it and I can't understand your objections, I'll let > you > > indulge your previously expressed wish to write a transaction > > manager. You > > might also get that wish fulfilled if you say the following is > > obvious. I > > thought it was, but I don't think we have agreed on it. I'm writing it > > down to try to form a basis for discussion, which is currently missing. > > > > == > > > > Dave's mental model for invocations. > > > > Lets assume first you already have something representing the object > you > > are interested in (such as an ejb Remote interface object, mbean > thingy, > > aop-ized object, or some kind of proxy). Items marked with a * might > be > > removed for non-remotable objects. > > > > Key to symbols: > > > >\/ interceptor chain "invokeNext()" calls. > > > > > >\/ > >|| method/field access/... calls whose nature may vary > > depending on the > > application and that are not part of the interceptor/invocation > > framework. > > > >\/ > >\/ calls between "segments". These are of the form > invoke(invocation) > > on a particular object found by the current interceptor. > > > > .. sequence of interceptors in a chain. > > > >|| > >|| transport mechanism. For a remote object, this is the boundary > > between client and server. > > > > > > === > > > > > > Some program does something on the "object" > > > >\/ > >|| > > > > The Object > > > >\/ > >|| > > > > Something that knows about interceptor chains and metadata. It looks > at > > the method (or field access, ...) call and its environment and > determines > > what interceptor chain to use. It construc
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: Saturday, February 22, 2003 11:48 AM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] TxInterceptor split is still the best thing > since sliced bread > > > This is really boring and unpleasant, bill. We don't seem to I am sorry I am boring you. Summarized, my major concern with the TX refactor is that it will not work for clients that cannot have interceptor chains (i.e. non-Java), but support Tx propagation (CORBA) for all trans-attributes (specifically, NotSupported, and RequiresNew). I thought Marc's vision for creating these generic, transport specific invokers was to isolate the EJB Container from the transport layer, and I see this refactor as breaking this vision. The only way I see this working is if we have separate transport-specific interceptor chains on the server to support non-Java clients. I wanted to avoid this because this is what has happened when I put in support for multiple invokers. Client-side interceptor configuration became bloated. All this to avoid creating and passing over a TxId. See my point now? === As far as AOP goes, I'm hoping that as we implement services on top of the Framework and apply the framework to JMX and remoting, the requirements and API will be fleshed out as we iterate. I'd like the design of AOP to be driven by "real-world" requirements and applications rather than what we might think as the perfect (and probably bloated) design/API might be currently. I'm not afraid of throwing code out or having to modify huge amounts of code to iterate. Iteration is key. Allows us to get to market quick and to quickly notice bad designs. Didn't somebody say "Release early, release often"? Bill > have a shared > understanding of how interceptors ought to work with local and remote > calls. Most of your comments make no sense to me, and I think > contrariwise. I'll try to explain my view one more time, and > I'll write an > interceptor framework that satisfies my understanding of what is > needed for > mbeans, ejbs, remoting, and aop (which I don't understand all that well). > If you don't like it and I can't understand your objections, I'll let you > indulge your previously expressed wish to write a transaction > manager. You > might also get that wish fulfilled if you say the following is > obvious. I > thought it was, but I don't think we have agreed on it. I'm writing it > down to try to form a basis for discussion, which is currently missing. > > == > > Dave's mental model for invocations. > > Lets assume first you already have something representing the object you > are interested in (such as an ejb Remote interface object, mbean thingy, > aop-ized object, or some kind of proxy). Items marked with a * might be > removed for non-remotable objects. > > Key to symbols: > >\/ interceptor chain "invokeNext()" calls. > > >\/ >|| method/field access/... calls whose nature may vary > depending on the > application and that are not part of the interceptor/invocation > framework. > >\/ >\/ calls between "segments". These are of the form invoke(invocation) > on a particular object found by the current interceptor. > > .. sequence of interceptors in a chain. > >|| >|| transport mechanism. For a remote object, this is the boundary > between client and server. > > > === > > > Some program does something on the "object" > >\/ >|| > > The Object > >\/ >|| > > Something that knows about interceptor chains and metadata. It looks at > the method (or field access, ...) call and its environment and determines > what interceptor chain to use. It constructs an Invocation object that > includes an iterator over the selected chain, the method call data, and > some metadata. Then it starts the invocation down the chain. I will call > this a Container. I believe it corresponds to your aop Advisor(s). > >\/ > > Several interceptors (client side interceptors specific to the > object/class you are calling) > > . > >\/ > > * Transport selector interceptor. This examines the metadata and picks a > transport endpoint. It calls invoke(invocation) on the selected transport > endpoint. It does not call invocation.invokeNext(), so this may be the end > of the use of the original interceptor iterator. > >\/ >\/ > > * Transport endpoint. If this is a local "do nothing" transport, it may > simply call invocation.invokeNext(). Otherwise, it replaces the > interceptor iterator with one for the client side transport interceptor > stack. > >\/ > > * Several interceptors (client side interceptors specific to the transport > endpoint you are calling. Examples would include the XAResource > representing a remote jboss instance (whenever the branch is created, you > still need an XAResource, and it needs to
RE: [JBoss-dev] org.jboss.aop.MethodMetaData
> I also want to add that the current interface for Metadata, metadata > chains, > and how you configure metadata is open for debate. It probably is not a > complete definition and I'm open for suggestions. I'm hoping that as I > port > some of the current interceptors more requirements will be flushed out. > Persistence will be the big test. I don't have any very solid ideas yet, but I think these would be improvements: 1. Single level lookups with Object keys rather than String: Object getMetadata(Object key). Why force the guy storing the metadata to use a concealed hashmap with String keys? 2. Put the default metadata in the thing that supplies the chain of interceptors (Advisor?), and always add it first to what the Invocation gets. (rather than putting the default metadata in the Invocation directly. I have some code with these ideas, I'll try to commit it or send it to you later today. I think it will take some experimentation to get something that works really well. david > > 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
Re: [JBoss-dev] invite to irc channel of jboss
Hi! Just in case someone wonders where this IRC channel comes from: irc.redhat.com is part of the Freenode.net network, I just learned. The Freenode.net network was formerly known as openprojects.net. Ivar founded the #jboss channel months (or even years now ?) ago. Ciao, Tobias yuexiang wrote: Hi, we invite you to join the irc channel of jboss! I hope you can give advice and get more developers there for jboss project. Steps: (1) download xchat and install it. (2) in the server list, add new server : irc.redhat.com with port 6667 (3) /join #jboss We are waiting for you! yang --- 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] org.jboss.aop.MethodMetaData
> When an > Interceptor wants metadata, it walks the chain. Each > repository decides > whether or not it can resolve the metadata, or how to resolve > the metadata > reference based on the context of the Invocation. For example, for > MethodMetaData, the context of the Invocation is the method > name. My main > goal here it to: > > 1) Allow metadata to be programmitcally overriden generically > at runtime > > 2) Allow default metadata to be defined within an > application, JVM, and also > cluster-wide. And I really love that. Though I don't think it is the role of the interceptor to iterate over the Repositories but instead to some other component (such as the repository itself) to delegate the resolution down to the chain. It makes me think to the exact opposite of the Clasloader mechanism: try to load locally and if not present, ask parent (i.e. Servlet mode) --- 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] org.jboss.aop.MethodMetaData
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Bill
> Burke
> Sent: Monday, February 24, 2003 10:06 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [JBoss-dev] org.jboss.aop.MethodMetaData
>
>
>
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] Behalf Of David
> > Jencks
> > Sent: Monday, February 24, 2003 9:48 AM
> > To: [EMAIL PROTECTED]
> > Subject: RE: [JBoss-dev] org.jboss.aop.MethodMetaData
> >
> >
> > On 2003.02.24 09:14 Bill Burke wrote:
> > >
> > >
> > > > -Original Message-
> > > > From: [EMAIL PROTECTED]
> > > > [mailto:[EMAIL PROTECTED] Behalf Of
> > > David
> > > > Jencks
> > > > Sent: Saturday, February 22, 2003 1:43 PM
> > > > To: [EMAIL PROTECTED]
> > > > Subject: [JBoss-dev] org.jboss.aop.MethodMetaData
> > > >
> > > >
> > > >public Object resolve(Invocation invocation, String group, String
> > > attr)
> > > >{
> > > > Method method = MethodInvocation.getMethod(invocation);
> > > > return getMethodMetaData(method.getName(), group, attr);
> > > >}
> > > >
> > > > Am I missing something or is this code making the assumption that a
> > > > method's name provides sufficient discrimination amongst
> all possible
> > > > method metadata? If so, what is the architectural rationale behind
> > > that
> > > > usage?
> > > >
> > >
> > > EJB metadata does not take into account method arguments either.
> >
> > ???
> > Some ejb metadata appears to:
> > from ejb_jar_2_1.xsd, inside methodType, around line 1639
> >
> > 3.
> >
> > EJBNAME
> > METHOD
> >
> > PARAM-1
> > PARAM-2
> > ...
> > PARAM-n
> >
> >
> >
> >This style is used to refer to a single method within a
> >set of methods with an overloaded name. PARAM-1 through
> >PARAM-n are the fully-qualified Java types of the
> >method's input parameters (if the method has no input
> >arguments, the method-params element contains no
> >method-param elements). Arrays are specified by the
> >array element's type, followed by one or more pair of
> >square brackets (e.g. int[][]).
> >
> > [david-- there appears to be a mistake in the xsd, copying the last
> > sentence of style 2 at this point]
> >
> > Whidh ejb metadata are you referring to?
> >
>
> Didn't know. Sorry. *blush* Is this an EJB 2.1 thing? (hence
> ejb_jar_2_1.xsd).
>
> I can add this to MethodMetaData eventually. Iteration... But the whole
> point of the metadata is that Metadata repositories are chained. When an
> Interceptor wants metadata, it walks the chain. Each repository decides
> whether or not it can resolve the metadata, or how to resolve the metadata
> reference based on the context of the Invocation. For example, for
> MethodMetaData, the context of the Invocation is the method name. My main
> goal here it to:
>
> 1) Allow metadata to be programmitcally overriden generically at runtime
>
> 2) Allow default metadata to be defined within an application,
> JVM, and also
> cluster-wide.
>
I also want to add that the current interface for Metadata, metadata chains,
and how you configure metadata is open for debate. It probably is not a
complete definition and I'm open for suggestions. I'm hoping that as I port
some of the current interceptors more requirements will be flushed out.
Persistence will be the big test.
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] org.jboss.aop.MethodMetaData
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of David
> Jencks
> Sent: Monday, February 24, 2003 9:48 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [JBoss-dev] org.jboss.aop.MethodMetaData
>
>
> On 2003.02.24 09:14 Bill Burke wrote:
> >
> >
> > > -Original Message-
> > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED] Behalf Of
> > David
> > > Jencks
> > > Sent: Saturday, February 22, 2003 1:43 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: [JBoss-dev] org.jboss.aop.MethodMetaData
> > >
> > >
> > >public Object resolve(Invocation invocation, String group, String
> > attr)
> > >{
> > > Method method = MethodInvocation.getMethod(invocation);
> > > return getMethodMetaData(method.getName(), group, attr);
> > >}
> > >
> > > Am I missing something or is this code making the assumption that a
> > > method's name provides sufficient discrimination amongst all possible
> > > method metadata? If so, what is the architectural rationale behind
> > that
> > > usage?
> > >
> >
> > EJB metadata does not take into account method arguments either.
>
> ???
> Some ejb metadata appears to:
> from ejb_jar_2_1.xsd, inside methodType, around line 1639
>
> 3.
>
> EJBNAME
> METHOD
>
> PARAM-1
> PARAM-2
> ...
> PARAM-n
>
>
>
>This style is used to refer to a single method within a
>set of methods with an overloaded name. PARAM-1 through
>PARAM-n are the fully-qualified Java types of the
>method's input parameters (if the method has no input
>arguments, the method-params element contains no
>method-param elements). Arrays are specified by the
>array element's type, followed by one or more pair of
>square brackets (e.g. int[][]).
>
> [david-- there appears to be a mistake in the xsd, copying the last
> sentence of style 2 at this point]
>
> Whidh ejb metadata are you referring to?
>
Didn't know. Sorry. *blush* Is this an EJB 2.1 thing? (hence
ejb_jar_2_1.xsd).
I can add this to MethodMetaData eventually. Iteration... But the whole
point of the metadata is that Metadata repositories are chained. When an
Interceptor wants metadata, it walks the chain. Each repository decides
whether or not it can resolve the metadata, or how to resolve the metadata
reference based on the context of the Invocation. For example, for
MethodMetaData, the context of the Invocation is the method name. My main
goal here it to:
1) Allow metadata to be programmitcally overriden generically at runtime
2) Allow default metadata to be defined within an application, JVM, and also
cluster-wide.
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
[JBoss-dev] [ jboss-Bugs-692273 ] EntityContainer.flushCache using jmx-console
Bugs item #692273, was opened at 2003-02-24 17:11
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=692273&group_id=22866
Category: JBossServer
Group: v3.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Lior Kanfi (kanfil)
Assigned to: Nobody/Anonymous (nobody)
Summary: EntityContainer.flushCache using jmx-console
Initial Comment:
when calling EntityContainer.flushCache using commit
option A
the passivation of the cache is scheduled but later the
passivation is postpone eventough the entitybean is not
part of a lock nor a transaction.
the fix for the problem seem to be very easy.
in the EntityInstanceCahce.canPassivate the 3rd if
should be
else if !
(m_container.getLockManager().canPassivate(((EntityEnterpriseContext)ctx).getCacheKey()))
{
return false;
}
attached a trace log
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=692273&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] org.jboss.aop.MethodMetaData
On 2003.02.24 09:14 Bill Burke wrote:
>
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] Behalf Of
> David
> > Jencks
> > Sent: Saturday, February 22, 2003 1:43 PM
> > To: [EMAIL PROTECTED]
> > Subject: [JBoss-dev] org.jboss.aop.MethodMetaData
> >
> >
> >public Object resolve(Invocation invocation, String group, String
> attr)
> >{
> > Method method = MethodInvocation.getMethod(invocation);
> > return getMethodMetaData(method.getName(), group, attr);
> >}
> >
> > Am I missing something or is this code making the assumption that a
> > method's name provides sufficient discrimination amongst all possible
> > method metadata? If so, what is the architectural rationale behind
> that
> > usage?
> >
>
> EJB metadata does not take into account method arguments either.
???
Some ejb metadata appears to:
from ejb_jar_2_1.xsd, inside methodType, around line 1639
3.
EJBNAME
METHOD
PARAM-1
PARAM-2
...
PARAM-n
This style is used to refer to a single method within a
set of methods with an overloaded name. PARAM-1 through
PARAM-n are the fully-qualified Java types of the
method's input parameters (if the method has no input
arguments, the method-params element contains no
method-param elements). Arrays are specified by the
array element's type, followed by one or more pair of
square brackets (e.g. int[][]).
[david-- there appears to be a mistake in the xsd, copying the last
sentence of style 2 at this point]
Whidh ejb metadata are you referring to?
david
>
> 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
Re[2]: [JBoss-dev] JBoss-IDE 1.0.2 released !
Hello Bernd, BK> All works fine with the RC1 of eclipse 2.1 and JBoss-IDE 1.0.2. My envrionment is: BK> SuSE _linux 8.0 BK> Sun JDK 1.4.1_01 BK> JBoss 3.2 from cvs at Friday BK> eclipse 2.1 RC1 BK> Thanks a lot! Thanks a lot for your cooperation in the last days (: Hans --- 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] org.jboss.aop.MethodMetaData
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of David
> Jencks
> Sent: Saturday, February 22, 2003 1:43 PM
> To: [EMAIL PROTECTED]
> Subject: [JBoss-dev] org.jboss.aop.MethodMetaData
>
>
>public Object resolve(Invocation invocation, String group, String attr)
>{
> Method method = MethodInvocation.getMethod(invocation);
> return getMethodMetaData(method.getName(), group, attr);
>}
>
> Am I missing something or is this code making the assumption that a
> method's name provides sufficient discrimination amongst all possible
> method metadata? If so, what is the architectural rationale behind that
> usage?
>
EJB metadata does not take into account method arguments either.
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
[JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed
= ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net FOR DETAILS= = JAVA VERSION DETAILS java version "1.3.1_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_06-b01) Java HotSpot(TM) Server VM (build 1.3.1_06-b01, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE org.jboss.ejb.EJBDeployer --> EJBDeployerMBean qualified to EJBDeployerMBean org.jboss.ejb.ContainerPlugin --> Service qualified to Service org.jboss.ejb.InstanceCache --> StatisticsProvider qualified to StatisticsProvider org.jboss.ejb.EntityEnterpriseContext --> EJBContextImpl qualified to EJBContextImpl org.jboss.invocation.Invoker --> Remote qualified to Remote org.jboss.ejb.StatefulSessionContainer --> AbstractContainerInterceptor qualified to AbstractContainerInterceptor org.jboss.ejb.EjbModule --> EjbModuleMBean qualified to EjbModuleMBean org.jboss.ejb.plugins.StatefulSessionFilePersistenceManager --> StatefulSessionFilePersistenceManagerMBean qualified to StatefulSessionFilePersistenceManagerMBean org.jboss.ejb.timer.AbstractTimerSource --> AbstractTimerSourceMBean qualified to AbstractTimerSourceMBean org.jboss.ejb.timer.FilePersistenceManager --> FilePersistenceManagerMBean qualified to FilePersistenceManagerMBean org.jboss.ejb.timer.SchedulerTimerSource --> SchedulerTimerSourceMBean qualified to SchedulerTimerSourceMBean org.jboss.invocation.InvokerXAResource --> InvokerXAResourceMBean qualified to InvokerXAResourceMBean org.jboss.invocation.XATerminatorContainer --> XATerminatorContainerMBean qualified to XATerminatorContainerMBean org.jboss.invocation.http.server.HttpInvokerMBean --> ServiceMBean qualified to ServiceMBean org.jboss.invocation.local.LocalInvoker --> LocalInvokerMBean qualified to LocalInvokerMBean org.jboss.invocation.jrmp.server.JRMPInvoker --> JRMPInvokerMBean qualified to JRMPInvokerMBean org.jboss.invocation.pooled.server.PooledInvoker --> PooledInvokerMBean qualified to PooledInvokerMBean org.jboss.invocation.trunk.client.ConnectionManager --> ConnectionManagerMBean qualified to ConnectionManagerMBean org.jboss.invocation.trunk.client.TrunkInvokerProxy --> TrunkInvokerProxyMBean qualified to TrunkInvokerProxyMBean org.jboss.invocation.trunk.server.TrunkInvoker --> TrunkInvokerMBean qualified to TrunkInvokerMBean org.jboss.jms.asf.ServerSessionPoolLoader --> ServerSessionPoolLoaderMBean qualified to ServerSessionPoolLoaderMBean org.jboss.jms.jndi.JMSProviderLoader --> JMSProviderLoaderMBean qualified to JMSProviderLoaderMBean org.jboss.jmx.connector.RemoteMBeanServer --> MBeanServer qualified to MBeanServer org.jboss.jmx.connector.notification.JMSNotificationListener --> JMSNotificationListenerMBean qualified to JMSNotificationListenerMBean org.jboss.jmx.connector.notification.RMINotificationListener --> RMINotificationListenerMBean qualified to RMINotificationListenerMBean org.jboss.jmx.adaptor.rmi.RMIAdaptorService --> RMIAdaptorServiceMBean qualified to RMIAdaptorServiceMBean org.jboss.jmx.adaptor.xml.XMLAdaptorService --> XMLAdaptorServiceMBean qualified to XMLAdaptorServiceMBean org.jboss.jmx.adaptor.xml.XMLTestService --> XMLTestServiceMBean qualified to XMLTestServiceMBean org.jboss.jmx.connector.rmi.RMIConnectorImpl --> RMIConnectorImplMBean qualified to RMIConnectorImplMBean org.jboss.jmx.connector.ejb.EJBConnector --> EJBConnectorMBean qualified to EJBConnectorMBean org.jboss.jmx.connector.ConnectorFactoryService --> ConnectorFactoryServiceMBean qualified to ConnectorFactoryServiceMBean org.jboss.jmx.connector.notification.PollingNotificationListener --> PollingNotificationListenerMBean qualified to PollingNotificationListenerMBean org.jboss.logging.Log4jService --> Log4jServiceMBean qualified to Log4jServiceMBean org.jboss.logging.Log4jSocketServer --> Log4jSocketServerMBean qualified to Log4jSocketServerMBean org.jboss.naming.ExternalContext --> ExternalContextMBean qualified to ExternalContextMBean org.jboss.naming.JNDIView --> JNDIViewMBean qualified to JNDIViewMBean org.jboss.naming.NamingAlias --> NamingAliasMBean qualified to NamingAliasMBean org.jboss.naming.NamingService --> NamingServiceMBean qualified to NamingServiceMBean org.jboss.web.AbstractWebContainer --> AbstractWebContainerMBean qualified to AbstractWebContainerMBean WARNING: Some classes refer to other classes that were not found among the sources or on the classpath. (Perhaps the referred class doesn't exist? Hasn't been generated yet?) The referring classes do not import any fully qualified classes matching these classes. Since at least one package is imported, it is impossible for xjavadoc to figure out what package the referred classes belong to. The classes are: org.jboss.web.WebService --> WebServiceMBean qualified to WebSer
Re: [JBoss-dev] JBoss-IDE 1.0.2 released !
All works fine with the RC1 of eclipse 2.1 and JBoss-IDE 1.0.2. My envrionment is: SuSE _linux 8.0 Sun JDK 1.4.1_01 JBoss 3.2 from cvs at Friday eclipse 2.1 RC1 Thanks a lot! Bernd Bernd Koecke wrote: Hi Hans, the clean install did it! Now I can start and stop JBoss 3.2 (Fridays cvs version) out of the eclipse IDE. Now I will try it with the RC1 from last Friday. Many Thanks! Bernd Hans Dockter wrote: Hello Bernd, BK> I tried this version, but I still get the same error. The update was made by the BK> Install/Update Manager and a complete restart of the IDE. This is very disappointing ): I've installed linux (SuSE 8.1) to figure out this bug. I could reproduce it there and fixed it in a way that it at least works on my computer. You might remove org.jboss.ide.eclipse.* from the plugins and feature directory and install JBoss-IDE 1.0.2 again. It would be good to know if the other user who have experienced this bug also still have the same problem. Hans --- 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 -- Dipl.-Inform. Bernd Koecke UNIX-Entwicklung Schlund+Partner AG Fon: +49-721-91374-0 E-Mail: [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
[JBoss-dev] [ jboss-Bugs-692157 ] UnifiedClassLoader.getResources not working
Bugs item #692157, was opened at 2003-02-24 12: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: Juha Lindfors (juhalindfors) Date: 2003-02-24 14: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[2]: [JBoss-dev] JBoss-IDE 1.0.2 released !
Hello Bernd, BK> Do you tried it with M5 or the RC1 of eclipse? With M5. Hans --- 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] JBoss-IDE 1.0.2 released !
Hi Hans, the clean install did it! Now I can start and stop JBoss 3.2 (Fridays cvs version) out of the eclipse IDE. Now I will try it with the RC1 from last Friday. Many Thanks! Bernd Hans Dockter wrote: Hello Bernd, BK> I tried this version, but I still get the same error. The update was made by the BK> Install/Update Manager and a complete restart of the IDE. This is very disappointing ): I've installed linux (SuSE 8.1) to figure out this bug. I could reproduce it there and fixed it in a way that it at least works on my computer. You might remove org.jboss.ide.eclipse.* from the plugins and feature directory and install JBoss-IDE 1.0.2 again. It would be good to know if the other user who have experienced this bug also still have the same problem. Hans --- 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 -- Dipl.-Inform. Bernd Koecke UNIX-Entwicklung Schlund+Partner AG Fon: +49-721-91374-0 E-Mail: [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: [JBoss-dev] JBoss-IDE 1.0.2 released !
Hello Hans, Hans Dockter wrote: Hello Bernd, BK> I tried this version, but I still get the same error. The update was made by the BK> Install/Update Manager and a complete restart of the IDE. By the way. Have you used new launch configurations (as said in the releasenotes) ? Yes I used a new launch configuration. Now I will delete Jboss-IDE and all launch configurations and try a clean install. Do you tried it with M5 or the RC1 of eclipse? Bernd -- Dipl.-Inform. Bernd Koecke UNIX-Entwicklung Schlund+Partner AG Fon: +49-721-91374-0 E-Mail: [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re[2]: [JBoss-dev] JBoss-IDE 1.0.2 released !
Hello Bernd, BK> I tried this version, but I still get the same error. The update was made by the BK> Install/Update Manager and a complete restart of the IDE. By the way. Have you used new launch configurations (as said in the releasenotes) ? Hans --- 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[2]: [JBoss-dev] JBoss-IDE 1.0.2 released !
Hello Bernd, BK> I tried this version, but I still get the same error. The update was made by the BK> Install/Update Manager and a complete restart of the IDE. This is very disappointing ): I've installed linux (SuSE 8.1) to figure out this bug. I could reproduce it there and fixed it in a way that it at least works on my computer. You might remove org.jboss.ide.eclipse.* from the plugins and feature directory and install JBoss-IDE 1.0.2 again. It would be good to know if the other user who have experienced this bug also still have the same problem. Hans --- 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 -- 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] JBoss-IDE 1.0.2 released !
Hi Hans, Hans Dockter wrote: JBoss-IDE 1.0.2 is a maintenance release. A couple of problems with the launcher have been resolved. I tried this version, but I still get the same error. The update was made by the Install/Update Manager and a complete restart of the IDE. Bernd You DON'T need to download directly from sourceforge as we now use the Install/Update Manager from Eclipse. See the releasenotes: https://sourceforge.net/project/shownotes.php?group_id=22866&release_id=142049 Enjoy Hans --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development -- Dipl.-Inform. Bernd Koecke UNIX-Entwicklung Schlund+Partner AG Fon: +49-721-91374-0 E-Mail: [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
