Re: [JBoss-dev] Removing CachedConnectionInterceptor
The jca 1.0 spec features a number of examples of what an app server is supposed to support where the connection handle is left open between calls and hooked up on each call with an appropriate ManagedConnection. Set SpecCompliant true to enable this behavior. SpecCompliant false enables the more useful connection close checking. (At least this was the code as I left it). Of course you guys may not be interested in supporting the spec any more, especially in its sillier aspects such as this one. david jencks On Tuesday, September 23, 2003, at 07:59 AM, Adrian Brock wrote: On Tue, 2003-09-23 at 15:47, Bill Burke wrote: Adrian, Are we removing the CachedConnectionInterceptor? We have code in place to replace it? No, but the processing is only really necessary for three reasons. 1) Nonshared resources 2) BMT code that does late transaction binding: DataSource.getConnection() UserTransaction.begin() 3) Connection close checking (a debug feature that can be turned off in production) For more normal use it should have approx. zero impact Regards, Adrian 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 -- Adrian Brock Director of Support Back Office JBoss Group, LLC --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- 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] XMBean validation
It looks like dom4j can't find xerces. Has the boot code that loads xerces or the location of xerces in JBOSS_HOME/lib been changed recently? david jencks On Monday, August 11, 2003, at 09:28 AM, Alexey Loubyansky wrote: I have problems running a simple remote client that accesses SLSB in HEAD. The cause is: run: [java] (tm.DTXAResourceInterceptor 70 ) Creating a new mbean inst ance on client: jboss.tm:service=XAResourceInterceptor [java] Warning: Error occurred using JAXP to load a SAXParser. Will use Ael fred instead (remoting.InvokerRegistry68 ) Failed to load soap remoting transpor t: javax/xml/rpc/ServiceException [java] org.dom4j.DocumentException: Validation not supported for XMLReader: [EMAIL PROTECTED] Nested exception: http://xml.org/sax/featu res/validation Nested exception: Validation not supported for XMLReader: org.dom [EMAIL PROTECTED] Nested exception: http://xml.org/sax/features/vali dation [java] at org.dom4j.io.SAXReader.read(SAXReader.java:342) [java] at org.dom4j.io.SAXReader.read(SAXReader.java:218) [java] at org.jboss.mx.metadata.XMLMetaData.build(XMLMetaData.java:245) [java] at org.jboss.mx.modelmbean.XMBean.init(XMBean.java:214) [java] at org.jboss.mx.modelmbean.XMBean.init(XMBean.java:240) Did anyone see it? Thanks, alex --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/ direct;at.aspnet_072303_01/01 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] multiple deployment info entries for invoker.war
On Friday, July 11, 2003, at 01:29 PM, Scott M Stark wrote: The whole service life-cycle, deployer, dependency management layer needs to be rethought to come up with a more coherent behavior. Right now there are too many ways a collection of components can be brought into the server and insufficient knowledge of how this was done to allow startup/shutdown to be service based. There is too much reliance on the deployment as a first class thing rather than just a packaging of code and metadata. I don't know what you mean. Can you give a specific example? Some issues that need to be cleared up include: - Removing the metadata from the deployers to allow them to be useful across deployment versions as well as minimizing the importance of the deployment package. A current issue related to this is that a given deployment package is only assigned to a single deployer as dictated by the primary deployment descriptor. This is too limiting and J2EE centric a view of a deployment package. Again, I don't have any idea what you mean and an example would be very helpful. Personally, I think that the current version of XSLSubDeployer in head is very close to a good universal solution for deployment, with a couple of helpers that aren't yet written. The name XSLSubdeployer may not be ideal. I propose that all deployment is handled by a single chain of subdeployers. The chain links can be XSLSubDeployers and various things analogous to SARDeployer and ServiceConfigurator. XSLSubDeployer can be configured to look for and load into the DeploymentInfo any number of xml deployment descriptors, and to apply one or two xsl transformations of any xml documents that may be loaded. (There is a URIResolver that makes all loaded xml documents available to stylesheets). Currently this scheme is used in the jca deployer to construct standard jboss mbean deployment descriptors. This unfortunately results in excessively complicated xsl, at least with my level of xsl expertise. I think the solution to this problem is a wider variety of mbean configurators. For instance, it would be easy to write a configurator based on apache digester, which would apply rules to map xml elements to mbean construction and attribute setting. This might eliminate the need for complex metadata objects for, e.g., ejbs. Many if not all of the ejb configuration in the ejb metadata objects could be attributes of the container mbeans. The ejb-jar.xml and jboss.xml and possibly jbosscmp-jdbc.xml could be processed sequentially by sets of digester rules to directly create and configure the container mbeans. This would avoid the need to combine the 2 or 3 xml documents into one, which has proved to be an xsl nightmare. I think this will be more flexible and usable than a jaxb based solution which would require either combining the 2 or 3 documents into one, eliminating all redundancy (and introducing nightmare xsl), or a set of objects that delegate to each other depending on which document the required info actually came from. - Coming up with a well defined service life-cycle diagram that is honored under all use cases. One simple problem that exists now is that the life-cycle operations exposed by a service do not integrate with the dependency management service. Calling stop on a service does not stop its dependent components. This requires invoking stop on the ServiceController. I agree. I think this involves moving the lifecycle/dependency stuff out of ServiceController into a central dependency mbean triggered by mbean interceptors. I also think these interceptors can take over most or all of the ServiceMBeanSupport functionality. Are you aware of any other problems this proposal doesn't solve? - Being able to redeploy portions of a deployment. How can redeployment of a war in an ear be allowed for example? Well, I've found I can redeploy just about any subpackage by simply invoking redeploy on it through the jmx console. Please explain any problems you have found with this. Of course this does not mean that the need to redeploy is easy to detect automatically. If you have ideas on this please explain. - Better automation of choosing the appropriate deployment class loading model taking into account duplicate/conflicting classes, missing classes, etc. The issue is being able to go from minimal canonical packages that need a flat shared class loading model to heavy weight packages that include redundant and conflicting classes with respect to the server and/or other deployments. I agree this is still a problem. Do you think a good start would be to list a bunch of use cases? So let's fix it. Agreed. Thanks /** * David Jencks * Partner * Core Developers Network * http://www.coredevelopers.net **/ Scott Stark Chief Technology Officer JBoss Group, LLC On Thursday, July 10
Re: [JBoss-dev] Tyrex transaction manager
Most likely this is caused by bugs 731349 and/or 731363. These should be fixed in jb4. I've been offered a patch for 3.2 from a commercial company whose product depends on these bugs being fixed but it is unclear if JBossGroup will allow it to be applied. AFAIK no one wants to fix these in the 3.0 branch. david jencks On Thursday, June 26, 2003, at 07:11 AM, Oleg V. Safonov wrote: After deploy tyrex-tm-plugin I get next exception java.lang.IllegalStateException: The transaction is not yet or no longer active 2003-06-26 18:34:08,733 ERROR [org.jboss.ejb.EntityContainer] Starting failed java.lang.IllegalStateException: The transaction is not yet or no longer active at tyrex.tm.impl.TransactionImpl.enlistResource(TransactionImpl.java:600) at tyrex.tm.impl.TransactionImpl.enlistResource(TransactionImpl.java:565) at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEv entLi stener.enlist(TxConnectionManager.java:460) at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnect ionRe connected(TxConnectionManager.java:358) at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateCon necti on(BaseConnectionManager2.java:490) at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionM anage rProxy.allocateConnection(BaseConnectionManager2.java:798) at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(Wrapper DataS ource.java:102) at org.jboss.ejb.plugins.cmp.jdbc.SQLUtil.fixTableName(SQLUtil.java:39) at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCEntityBridge.init(JDBCEntit yBrid ge.java:119) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.initStoreManager(JDBCSt oreMa nager.java:438) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.start(JDBCStoreManager. java: 372) at org.jboss.ejb.plugins.CMPPersistenceManager.start(CMPPersistenceManager .java :170) at org.jboss.ejb.EntityContainer.startService(EntityContainer.java:339) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:192 ) at sun.reflect.GeneratedMethodAccessor35.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccesso rImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanD ispat cher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControlle r.jav a:966) at $Proxy11.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:392) at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccesso rImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanD ispat cher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177) at $Proxy37.start(Unknown Source) at org.jboss.ejb.EjbModule.startService(EjbModule.java:329) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:192 ) at sun.reflect.GeneratedMethodAccessor35.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccesso rImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanD ispat cher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControlle r.jav a:966) at $Proxy11.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:392) at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccesso rImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanD ispat cher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177) at $Proxy24.start(Unknown Source) at org.jboss.ejb.EJBDeployer.start(EJBDeployer.java:540) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:832) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:640) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:613) at sun.reflect.GeneratedMethodAccessor29.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccesso rImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanD ispat cher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549
Re: [JBoss-dev] XSLSubDeployer improvements and jca 1.5 mdb deployment
On Monday, June 16, 2003, at 10:57 PM, Bill Burke wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David Jencks Sent: Monday, June 16, 2003 12:32 AM To: [EMAIL PROTECTED] Subject: [JBoss-dev] XSLSubDeployer improvements and jca 1.5 mdb deployment I've modified the deployment system to allow for multiple xml deployment descriptors. XSLSubDeployer can be configured via the Properties valued DdNameToKeyMap property to import the specified dds and store them in the DeploymentInfo under the specified key. The properties lines look like dd-name=KEY. I've also added the new DeploymentInfoURIResolverFactory which can resolve uris to documents in the current deployment info or documents in other DeploymentInfo mbeans. URIs are of the form jboss-di://deployment-info-name#key#xpath expression. The deployment-info-name and xpath-expression are optional. The DeploymentInfoDocumentURIResolver is now obsolete. I've discovered that use of two # characters in a URI is ungrammatical so the first will be changed to ! shortly. If we're moving to a meta object model, I'm not convinced we are, I am unconvinced anything more than mbeans is necessary. Configuring mbeans that do the work directly has the nice property that you can see and change what the properties are directly in the jmx console. please tell me why we need point pointers into the documents of different deployments? This has been there since the beginning of jb4. The ra.xml from an adapter is transformed into xmbean descriptors, which need to be included or accessed somehow when an mbean based on one of them is deployed, i.e. when a connection factory is deployed. The change I just made is to let you get to more than one xml doc in a single deployment info, something the current metadata classes do in hardcoded java. BTW, I am not completely thrilled with the complexity of the xsl stylesheets I'm currently using and am looking for something simpler. Apache Commons Digester looks like a possibility. david Bill --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] XSLSubDeployer improvements and jca 1.5 mdb deployment
Yes indeed, many thanks. I need to retest since I made some additions since the original commit. Sorry for the delay on this, I've been having trouble connecting to cvs today. david jencks On Tuesday, June 17, 2003, at 03:05 PM, Adrian Brock wrote: Hi David, Did you forget to commit stylesheets/JMSMDBTemplate.xsl? Regards, Adrian Adrian Brock Director of Support Back Office JBoss Group, LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Jencks Sent: 16 June 2003 05:32 To: [EMAIL PROTECTED] Subject: [JBoss-dev] XSLSubDeployer improvements and jca 1.5 mdb deployment I've modified the deployment system to allow for multiple xml deployment descriptors. XSLSubDeployer can be configured via the Properties valued DdNameToKeyMap property to import the specified dds and store them in the DeploymentInfo under the specified key. The properties lines look like dd-name=KEY. I've also added the new DeploymentInfoURIResolverFactory which can resolve uris to documents in the current deployment info or documents in other DeploymentInfo mbeans. URIs are of the form jboss-di://deployment-info-name#key#xpath expression. The deployment-info-name and xpath-expression are optional. The DeploymentInfoDocumentURIResolver is now obsolete. I've discovered that use of two # characters in a URI is ungrammatical so the first will be changed to ! shortly. I've simplified the ejb container mbeans to remove common code to the Container class and allow deployment of MDBs with arbitrary interfaces per the ejb 2.1 spec. However, only jms MessageListener MDBs can be deployed at the moment. Deployment proceeds by constructing and deploying an ActivationSpec xmbean instance from the ejb 2.0 mdb dd. Finally, I've modified message delivery to always use the jmsra jca 1.5 adapter and correspondingly removed the asf classes. thanks david jencks /** * David Jencks * Partner * Core Developers Network * http://www.coredevelopers.net **/ --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] XSLSubDeployer improvements and jca 1.5 mdb deployment
On Monday, June 16, 2003, at 01:53 PM, Scott M Stark wrote: This is not consistent with the move to extract the metadata parsing from the current deployers into filters or interceptors associated with the deployers. The key issue is to support transformation of multiple versions of the various descriptors into metadata used by the current deployer. Please explain your point of view. The XSLSubdeployer IS an interceptor. This change is in the direction of allowing a single chain of subdeployers that can deploy anything. Why would we want to preserve the current ejb metadata classes? Converting the XSLSubDeployer into a filter for the different transformations that need to be supported is also something that make more sense than leaving this as a deployer. We also need the ability for multiple deployers to operation on a given deployment if we do not already. As noted, my changes to XSLSubDeployer supply a considerable amount of this functionality. They are not proposed as a complete solution, but they do allow deployment of mdbs in accordance with the jca 1.5 spec. david jencks /** * David Jencks * Partner * Core Developers Network * http://www.coredevelopers.net **/ Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, June 15, 2003 9:32 PM Subject: [JBoss-dev] XSLSubDeployer improvements and jca 1.5 mdb deployment I've modified the deployment system to allow for multiple xml deployment descriptors. XSLSubDeployer can be configured via the Properties valued DdNameToKeyMap property to import the specified dds and store them in the DeploymentInfo under the specified key. The properties lines look like dd-name=KEY. I've also added the new DeploymentInfoURIResolverFactory which can resolve uris to documents in the current deployment info or documents in other DeploymentInfo mbeans. URIs are of the form jboss-di://deployment-info-name#key#xpath expression. The deployment-info-name and xpath-expression are optional. The DeploymentInfoDocumentURIResolver is now obsolete. I've discovered that use of two # characters in a URI is ungrammatical so the first will be changed to ! shortly. I've simplified the ejb container mbeans to remove common code to the Container class and allow deployment of MDBs with arbitrary interfaces per the ejb 2.1 spec. However, only jms MessageListener MDBs can be deployed at the moment. Deployment proceeds by constructing and deploying an ActivationSpec xmbean instance from the ejb 2.0 mdb dd. Finally, I've modified message delivery to always use the jmsra jca 1.5 adapter and correspondingly removed the asf classes. thanks david jencks /** * David Jencks * Partner * Core Developers Network * http://www.coredevelopers.net **/ --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] XSLSubDeployer improvements and jca 1.5 mdb deployment
I've modified the deployment system to allow for multiple xml deployment descriptors. XSLSubDeployer can be configured via the Properties valued DdNameToKeyMap property to import the specified dds and store them in the DeploymentInfo under the specified key. The properties lines look like dd-name=KEY. I've also added the new DeploymentInfoURIResolverFactory which can resolve uris to documents in the current deployment info or documents in other DeploymentInfo mbeans. URIs are of the form jboss-di://deployment-info-name#key#xpath expression. The deployment-info-name and xpath-expression are optional. The DeploymentInfoDocumentURIResolver is now obsolete. I've discovered that use of two # characters in a URI is ungrammatical so the first will be changed to ! shortly. I've simplified the ejb container mbeans to remove common code to the Container class and allow deployment of MDBs with arbitrary interfaces per the ejb 2.1 spec. However, only jms MessageListener MDBs can be deployed at the moment. Deployment proceeds by constructing and deploying an ActivationSpec xmbean instance from the ejb 2.0 mdb dd. Finally, I've modified message delivery to always use the jmsra jca 1.5 adapter and correspondingly removed the asf classes. thanks david jencks /** * David Jencks * Partner * Core Developers Network * http://www.coredevelopers.net **/ --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Thread management
What do you need? I'd rather avoid having 895 different thread pool implementations for the 65 actual uses. The particular interface in the work package is spec mandated, but that doesn't mean we can't have shared infrastructure. david jencks On 2003.06.04 22:45 Andrew C. Oliver wrote: Isn't quite what I need, no biggy. I'll roll my own. On 6/4/03 5:04 PM, Andrew C. Oliver [EMAIL PROTECTED] wrote: Thanks man. On 6/4/03 12:16 PM, Adrian Brock [EMAIL PROTECTED] wrote: jboss-head in the connector module org.jboss.resource.work Adrian Brock Director of Support Back Office JBoss Group, LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew C. Oliver Sent: 04 June 2003 17:05 To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Thread management Thanks Adrian, Any idea on module/dir/tag? -Andy On 6/4/03 11:27 AM, Adrian Brock [EMAIL PROTECTED] wrote: Hi Andrew, David has been working on some thread management stuff for the Work contract in jca 1.5 I think it is still very simple at the moment. Regards, Adrian Adrian Brock Director of Support Back Office JBoss Group, LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew C. Oliver Sent: 04 June 2003 16:05 To: [EMAIL PROTECTED] Subject: [JBoss-dev] Thread management I'm getting very close to needing to work on multi-threading the JMX SMTP service for Jboss. My approach is to steal what I can from Apache JAMES, though I've re-written a good part of it, ripped out all of the Avalon stuff (even the Avalon folks whine that JAMES uses Avalon incorrectly, but then again they whine about that for every existing use of Avalon). Its a 70-80% rewrite, 10-20% refactor and 10-20% copy (though its mostly dumb stuff like stream subclasses). In doing this I've ripped out the Watchdog stuff and hence the thread-management. I have my own crazy ideas for how threads should be handled, but first I want to check to see if Jboss has some tried-and-true generic thread management code lying around that I can use? Nothing jumped out at me in perusing the sources. Any pointers would be much appreciated. If enough caffeine finds me, I should have an alpha by JavaONE. Thanks, Andy PS. If you're bored you can read about it here: http://linuxintegrators.com/hl30/blog/general?permalink=JBoss+ Mail%3A+SMTP.h tml here: http://linuxintegrators.com/hl30/blog/technology?permalink=JBo ss+Mail.ht ml here: http://linuxintegrators.com/hl30/blog/technology?permalink=JBoss+Mail%2C +the +more+I+think+about+it.html and here: http://linuxintegrators.com/hl30/blog/technology?permalink=So+quit+whini ng+a nd+just+do+it.html Note that my time estimates were a bit under in part because I have a different audience than just want to use as my mail server, do as little work as possible, in part because they just were ;-) -- Andrew C. Oliver http://www.superlinksoftware.com/poi.jsp Custom enhancements and Commercial Implementation for Jakarta POI http://jakarta.apache.org/poi For Java and Excel, Got POI? --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] ServiceController Invalid transition from...
They've been in jboss 4 for several months. How many of them are necessary is another question. david jencks On 2003.05.27 21:56 Nathan Phelps wrote: Are these messages new? What do they mean? They are all over the place in JB4 and I don't recall seeing them before. 2003-05-27 20:45:21,328 DEBUG [org.jboss.system.ServiceController] Creating service jboss:service=EJBTimerService 2003-05-27 20:45:21,328 INFO [org.jboss.system.ServiceController] returning from create for service jboss:service=EJBTimerService, invalid transition from CREATED . 2003-05-27 20:45:21,859 DEBUG [org.jboss.system.ServiceController] starting service jboss:service=EJBTimerService 2003-05-27 20:45:21,859 INFO [org.jboss.system.ServiceController] Returning from start request for service: jboss:service=EJBTimerService, invalid transition from state RUNNING 2003-05-27 20:45:22,109 DEBUG [org.jboss.system.ServiceController] starting service jboss.admin:service=PluginManager 2003-05-27 20:45:22,109 INFO [org.jboss.system.ServiceController] Returning from start request for service: jboss.admin:service=PluginManager, invalid transition from state CONFIGURED . 2003-05-27 20:45:22,109 DEBUG [org.jboss.system.ServiceController] starting service jboss.admin:service=PluginManager 2003-05-27 20:45:22,109 INFO [org.jboss.system.ServiceController] Returning from start request for service: jboss.admin:service=PluginManager, invalid transition from state CONFIGURED . 2003-05-27 20:45:22,109 DEBUG [org.jboss.system.ServiceController] starting service jboss.admin:service=PluginManager 2003-05-27 20:45:22,109 INFO [org.jboss.system.ServiceController] Returning from start request for service: jboss.admin:service=PluginManager, invalid transition from state CONFIGURED . 2003-05-27 20:45:23,640 DEBUG [org.jboss.system.ServiceController] starting service jboss.jca:service=BaseWorkManager 2003-05-27 20:45:23,640 INFO [org.jboss.system.ServiceController] Returning from start request for service: jboss.jca:service=BaseWorkManager, invalid transition from state CONFIGURED . etc. . 2003-05-27 20:45:48,750 DEBUG [org.jboss.system.ServiceController] Creating service jboss.j2ee:jndiName=ejb/jmx/ejb/Adaptor,service=EJB 2003-05-27 20:45:48,750 INFO [org.jboss.system.ServiceController] returning from create for service jboss.j2ee:jndiName=ejb/jmx/ejb/Adaptor,service=EJB, invalid transition from CREATED Thanks, Nathan !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 3.2//EN HTML HEAD META HTTP-EQUIV=Content-Type CONTENT=text/html; charset=us-ascii META NAME=Generator CONTENT=MS Exchange Server version 6.0.4630.0 TITLEServiceController quot;Invalid transition from...quot;/TITLE /HEAD BODY !-- Converted from text/rtf format -- P ALIGN=LEFTSPAN LANG=en-usFONT SIZE=2 FACE=ArialAre these messages new?nbsp; What do they mean?nbsp; T/FONT/SPANSPAN LANG=en-us/SPANSPAN LANG=en-usFONT SIZE=2 FACE=Arialhey are all over the place/FONT/SPANSPAN LANG=en-us/SPANSPAN LANG=en-us FONT SIZE=2 FACE=Arialin JB4/FONT/SPANSPAN LANG=en-us/SPANSPAN LANG=en-us FONT SIZE=2 FACE=Arialand I don/FONT/SPANSPAN LANG=en-us/SPANSPAN LANG=en-usFONT SIZE=2 FACE=Arial#8217;/FONT/SPANSPAN LANG=en-us/SPANSPAN LANG=en-usFONT SIZE=2 FACE=Arialt recall seeing them before./FONT/SPANSPAN LANG=en-us/SPANSPAN LANG=en-us/SPAN/P P ALIGN=LEFTSPAN LANG=en-usFONT SIZE=2 FACE=Arial2003-05-27 20:45:21,328 DEBUG [org.jboss.system.ServiceController] Creating service jboss:service=EJBTimerService/FONT/SPAN/P P ALIGN=LEFTSPAN LANG=en-usFONT SIZE=2 FACE=Arial2003-05-27 20:45:21,328 INFOnbsp; [org.jboss.system.ServiceController] returning from create for service jboss:service=EJBTimerService,/FONT/SPANSPAN LANG=en-usB/B/SPANSPAN LANG=en-usB FONT SIZE=2 FACE=Arialinvalid transition from CREATED/FONT/B/SPANSPAN LANG=en-us/SPANSPAN LANG=en-us/SPAN/P P ALIGN=LEFTSPAN LANG=en-usFONT SIZE=2 FACE=Arial#8230;/FONT/SPANSPAN LANG=en-us/SPANSPAN LANG=en-us/SPAN/P P ALIGN=LEFTSPAN LANG=en-usFONT SIZE=2 FACE=Arial2003-05-27 20:45:21,859 DEBUG [org.jboss.system.ServiceController] starting service jboss:service=EJBTimerService/FONT/SPAN/P P ALIGN=LEFTSPAN LANG=en-usFONT SIZE=2 FACE=Arial2003-05-27 20:45:21,859 INFOnbsp; [org.jboss.system.ServiceController] Returning from start request for service: jboss:service=EJBTimerService,/FONT/SPANSPAN LANG=en-usB/B/SPANSPAN LANG=en-usB FONT SIZE=2 FACE=Arialinvalid transition from state RUNNING/FONT/B/SPANSPAN LANG=en-us/SPANSPAN LANG=en-us/SPAN/P P ALIGN=LEFTSPAN LANG=en-usFONT SIZE=2 FACE=Arial2003-05-27 20:45:22,109 DEBUG [org.jboss.system.ServiceController] starting service jboss.admin:service=PluginManager/FONT/SPAN/P P ALIGN=LEFTSPAN LANG=en-usFONT SIZE=2 FACE=Arial2003-05-27 20:45:22,109 INFOnbsp; [org.jboss.system.ServiceController] Returning from start request for service: jboss.admin:service=PluginManager,/FONT/SPANSPAN LANG=en-usB/B/SPANSPAN LANG=en-usB FONT SIZE=2
Re: AW: [JBoss-dev] JB4DR1 Deadline MAY 26
If we can include/redistribute the jaxm libraries adding the ability to accept jaxm calls from a jca 1.5 resource adapter to an mdb is very easy. I can't understand the license terms and the last time I asked I got no response. Is there another jca part to the webservices? thanks david jencks On 2003.04.04 01:44 Jung , Dr. Christoph wrote: Until 26th of May, I will have a version of W2EE deployment ready (at least the subset of the webservices.xml and jaxrpc-mapping.xml that can be easily mapped via a XSL-driven WebServiceDeployer to the existing web-service.xml/AxisService; deployer hooks in EJBDeployer+WARDeployer-WebServiceDeployer must be coordinated with Bill? And Scott?). I will also have catered for a reasonable auto-registration of web service wsdl in uddi until then. I cannot guarantuee Xdoclet support to generate J2EE1.4 webservices.xml and JAXRPC mappings. Maybe there will be a volunteer for this (one of the xpetstore guys was interested in trying that out?). Maybe the xdoclet team will have something in that direction anyway ... I would delay all web service extensions of JCA and JMS (just a guess from a quick look into the draft) and the tighter integration of the Axis and Jboss invocation stacks then after JB4DR1. CGJ -Ursprüngliche Nachricht- Von: Bill Burke [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 4. April 2003 00:28 An: [EMAIL PROTECTED] Betreff: RE: [JBoss-dev] JB4DR1 Deadline MAY 26 JBoss Remoting AOP + tx, security, versioning, remoting, clustering, txlock, caching DTM (waiting on David's response) EMB (Enterprise Media Beans) JUDDI integration If I can get it done: AOP + EJB (packaged extensions to EJB) and don't forget Nukes! Anybody got anything to add to this list? Who doesn't think they'll be done by May 5th? Who thinks they'll be cutting it close? Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Dain Sundstrom Sent: Thursday, April 03, 2003 4:48 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JB4DR1 Deadline MAY 26 Ok then there are 4 weeks to get the new stuff done? Marc, Bill, sure we could do a release but what difference would it make if the new features are not in it. Is this a release just to show off AOP? What about any of the other new stuff? Just give the users a solid 3.2 and they will be happy. -dain On Thursday, April 3, 2003, at 03:30 PM, Bill Burke wrote: It will be ready and stable. Functionality freeze is May 5th. What functionality doesn't make it by then will be left out of the release. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Dain Sundstrom Sent: Thursday, April 03, 2003 4:01 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] JB4DR1 Deadline MAY 26 I think you are delusional if you think JB4 will be ready for JavaOne. -dain On Thursday, April 3, 2003, at 02:47 PM, marc fleury wrote: Guys, We are thinking a lot about the forthcoming JB4 release. It is a truly exciting step for us as we believe we will bring a programming style, whose time has come, to a mass audience. AOP as Bill says is a clear wave for system level services on par with OOP. On top of it and also as a proof of how powerful the approach is we still develop a full J2EE server. Meaning that you can choose to live in the J2EE world work on JBoss J2EE and access all the prepackaged AOP goodies as you have been doing since JBoss2.0. There seems to be a lot of fear at SUN from what I can tell in the press, that we will abandon J2EE. We love J2EE. When really we will support J2EE for the forthcoming future. Never do we talk about abandoning J2EE, we just let the user access core functionality in the open server and think at the AOP level. A more fundamental construct of the framework. The reason we are almost there is that it is also a very old implementation in JBoss. We have been doing it for a long time but never talked/packaged it this way. We make it easy for you to leverage the AOP layer. The implementation is old the way you interact with JBoss is new. It can also be old if you decide to stay at the J2EE level which will be fully supported. But you are now invited to roam in the core JBoss system, in fact you may find it very cozy as you port POJO based applications to JBoss. There will be a stabilization period though. We are making an aggressive push to release JB4 by JavaONE with all our resources dedicated to implementing the final AOP system aspects and porting some of the existing code to that. We're making an aggressive push to release JBoss 4.0 by JavaOne. We're targeting May 26th. That leaves us 2 month from now. I
Re: [JBoss-dev] How do I clean up these hsqldb shutdown exceptions?
On 2003.04.03 07:36 [EMAIL PROTECTED] wrote: torsdagen den 3 april 2003 kl 07.32 skrev David Jencks: I'm not sure what your point is, Victor. The exceptions Scott saw were a result of a change I made in the last few days to improve the shutdown behavior of the pools, something I've been somewhat worried about since I wrote them. The fix was to change the mbean dependency between the hslq mbean and the datasource mbeans. My point being a concern for : http://c2.com/cgi/wiki?ComplexityAsDebt I'm well aware of this viewpoint and basically agree with it: another catch-phrase is LOC spent, not LOC written. However, please explain how it is relevant to the refactoring that caused the exceptions to show up. The possible remaining problem is, what happens to connections that are checked out to clients if the db is shut down? For say Oracle, you get a lot of dead connections. For an in-vm java db, it's not clear to me how to make the shutdown wait until all connections are returned. This doesn't have anything to do with hsql AFAIK. One could imagine a reconnect policy negotiated from a service state repository. I can imagine a lot of things, but not how this would provide a reasonable value/complexity tradeoff over the current situation. david jencks --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Does clustering work on OS X?
This has never happened to me, and I have done some (extremely informal) clustering tests by (accidentally) running all on a network with other jboss's running. I still haven't upgraded jdk's however, still on 1.4.1dp10. david jencks On 2003.04.03 02:36 Dain Sundstrom wrote: I'm just running 'all', and am not connecting to anything. -dain On Thursday, April 3, 2003, at 01:12 AM, Stephen Coy wrote: As in just running the all config, or are you actually clustering with something else? Running all certainly works in 3.2 - I've not tried HEAD in a while. In fact, I've run all on a Mac and linux box together without problems using JDK 1.4.1. Steve Coy On Thursday, April 3, 2003, at 04:32 PM, Dain Sundstrom wrote: Does clustering in jboss-head work for anyone on OS X? Whenever I try to shutdown jboss-head on my powerbook the entire os locks up until I unplug my wireless access point and 'killall -9 java'. This can take like 30 minutes to get my laptop responsive again. [12:27:50] dain$ java -version java version 1.4.1_01 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-39) Java HotSpot(TM) Client VM (build 1.4.1_01-14, mixed mode) -dain --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] org.jboss.test.jca.test.JDBCStatementTestsConnectionUnitTestCase
Fix that works on my machine is now checked in david jencks On 2003.04.01 13:56 Scott M Stark wrote: The current 3.2 branch has a new failure in the JDBCStatementTestsConnectionUnitTestCase. The server side exception is: 10:52:20,421 INFO [MainDeployer] Deployed package: file:/C:/cvs/JBoss3.2/jboss-3.2/testsuite/output/lib/jbosstestdriver.jar 10:52:20,656 ERROR [LogInterceptor] RuntimeException: java.lang.IllegalStateException: Trying to return an unknown connection2! null at org.jboss.resource.connectionmanager.CachedConnectionManager.unregisterConnection(CachedConnectionManager.java:275) at org.jboss.resource.connectionmanager.NoTxConnectionManager$NoTxConnectionEventListener.connectionErrorOccurred(NoTxConnectionM anager.java:1 55) at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.broadcastConnectionError(BaseWrapperManagedConnection.java:309) at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.checkValid(BaseWrapperManagedConnection.java:255) at org.jboss.resource.adapter.jdbc.local.LocalManagedConnectionFactory.matchManagedConnections(LocalManagedConnectionFactory.java :179) at org.jboss.resource.connectionmanager.InternalManagedConnectionPool.getConnection(InternalManagedConnectionPool.java:123) at org.jboss.resource.connectionmanager.JBossManagedConnectionPool$OnePool.getConnection(JBossManagedConnectionPool.java:648) at org.jboss.resource.connectionmanager.BaseConnectionManager2.getManagedConnection(BaseConnectionManager2.java:412) at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:487) at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.j ava:780) at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:102) at org.jboss.test.jca.ejb.JDBCStatementTestsConnectionSessionBean.testConnectionObtainable(JDBCStatementTestsConnectionSessionBea n.java:68) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:629) at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:186) at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:72) at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:84) 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:117) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:198) at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122) at org.jboss.ejb.StatelessSessionContainer.internalInvoke(StatelessSessionContainer.java:322) at org.jboss.ejb.Container.invoke(Container.java:678) 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.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:358) at java.lang.reflect.Method.invoke(Native Method) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:236) at sun.rmi.transport.Transport$1.run(Transport.java:147) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:143) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701) at java.lang.Thread.run(Thread.java:479) The junit client side view of this exception is: RemoteException occurred in server thread; nested exception is: java.rmi.ServerException: RuntimeException; nested exception is: java.lang.IllegalStateException: Trying to return an unknown connection2! null java.rmi.ServerException: RemoteException occurred in server thread; nested exception is: java.rmi.ServerException: RuntimeException; nested exception is: java.lang.IllegalStateException: Trying to return an unknown connection2! null java.rmi.ServerException: RuntimeException; nested exception is: java.lang.IllegalStateException: Trying to return an unknown connection2! null java.lang.IllegalStateException: Trying to return an unknown connection2! null at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer
Re: [JBoss-dev] How do I clean up these hsqldb shutdown exceptions?
Should be fixed in cvs. There may still be exceptions if you stop the hsqldb mbean while there are still connections checked out to applications using them, but I don't think this is realistic to try to fix at this point. david jencks On 2003.04.01 23:06 Scott M Stark wrote: There are still two annonying exception generated on shutdown of the server coming from the shutdown of the HypersonicDatabase service. Maybe this is a problem with the lifecycle implementation of this service, or dependency ordernig, but it needs to be cleaned up. There is also an NPE in here that most likely should not be occuring as well. 20:00:42,323 INFO [MainDeployer] Undeploying file:/C:/usr/JBoss3.2/jboss-3.2/build/output/jboss-3.2 .0RC5/server/default/deploy/hsqldb-ds.xml 20:00:42,323 INFO [HypersonicDatabase] Stopping 20:00:42,603 INFO [HypersonicDatabase] Database closed clean 20:00:42,603 INFO [HypersonicDatabase] Stopped 20:00:42,603 INFO [JBossManagedConnectionPool] Stopping 20:00:42,603 INFO [STDOUT] Tue Apr 01 20:00:42 PST 2003 SHUTDOWN : System.exit() was not called 20:00:42,603 INFO [JBossManagedConnectionPool] Exception destroying ManagedConnection org.jboss.resource.JBossResourceException: SQLException; - nested throwable: (java.sql.SQLException: The database is shutdown in statement [DISCONNECT]) at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.checkException(BaseWrapperMa nagedConnection.java:445) at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.destroy(BaseWrapperManagedCo nnection.java:229) at org.jboss.resource.connectionmanager.InternalManagedConnectionPool.doDestroy(InternalMana gedConnectionPool.java:374) at org.jboss.resource.connectionmanager.InternalManagedConnectionPool.flush(InternalManagedC onnectionPool.java:272) at org.jboss.resource.connectionmanager.InternalManagedConnectionPool.shutdown(InternalManag edConnectionPool.java:307) at org.jboss.resource.connectionmanager.JBossManagedConnectionPool$OnePool.shutdown(JBossMan agedConnectionPool.java:675) at org.jboss.resource.connectionmanager.JBossManagedConnectionPool.stopService(JBossManagedC onnectionPool.java:373) at org.jboss.system.ServiceMBeanSupport.stop(ServiceMBeanSupport.java:236) 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.stop(Unknown Source) at org.jboss.system.ServiceController.stop(ServiceController.java:464) at org.jboss.system.ServiceController.stop(ServiceController.java:456) 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.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177) at $Proxy5.stop(Unknown Source) at org.jboss.deployment.SARDeployer.stop(SARDeployer.java:389) 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.mx.util.JMXInvocationHandler.invoke(JMXInvocationHandler.java:177) at $Proxy16.stop(Unknown Source) at org.jboss.deployment.XSLSubDeployer.stop(XSLSubDeployer.java:225) at org.jboss.deployment.MainDeployer.stop(MainDeployer.java:497) at org.jboss.deployment.MainDeployer.undeploy(MainDeployer.java:480) at org.jboss.deployment.MainDeployer.shutdown(MainDeployer.java:368) 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.server.ServerImpl$ShutdownHook.shutdownDeployments(ServerImpl.java:792) at org.jboss.system.server.ServerImpl$ShutdownHook.shutdown(ServerImpl.java:770) at org.jboss.system.server.ServerImpl$ShutdownHook.run(ServerImpl.java:758) + nested throwable: java.sql.SQLException: The database is shutdown in statement [DISCONNECT] at org.hsqldb.Trace.getError(Unknown Source) at org.hsqldb.Result.init(Unknown Source) at org.hsqldb.jdbcConnection.executeHSQL(Unknown Source) at org.hsqldb.jdbcConnection.execute(Unknown Source) at org.hsqldb.jdbcConnection.close(Unknown Source
Re: [JBoss-dev] How do I clean up these hsqldb shutdown exceptions?
I'm not sure what your point is, Victor. The exceptions Scott saw were a result of a change I made in the last few days to improve the shutdown behavior of the pools, something I've been somewhat worried about since I wrote them. The fix was to change the mbean dependency between the hslq mbean and the datasource mbeans. The possible remaining problem is, what happens to connections that are checked out to clients if the db is shut down? For say Oracle, you get a lot of dead connections. For an in-vm java db, it's not clear to me how to make the shutdown wait until all connections are returned. This doesn't have anything to do with hsql AFAIK. I'm not getting paid for this work. david jencks On 2003.04.02 18:28 [EMAIL PROTECTED] wrote: ho ... one is wondering as why this epost conversation ever took place ! Yes - because somebody hussy homestedinding the no-sphere and is not checking bugs in previous LOC also then are expecting (non-paid) peoples to fix the bugs in that LOC - hoho ___ Peter_f ___ is steaming ... onsdagen den 2 april 2003 kl 17.15 skrev David Jencks: Should be fixed in cvs. There may still be exceptions if you stop the hsqldb mbean while there are still connections checked out to applications using them, but I don't think this is realistic to try to fix at this point. david jencks On 2003.04.01 23:06 Scott M Stark wrote: There are still two annonying exception generated on shutdown of the server coming from the shutdown of the HypersonicDatabase service. Maybe this is a problem with the lifecycle implementation of this service, or dependency ordernig, but it needs to be cleaned up. There is also an NPE in here that most likely should not be occuring as well. 20:00:42,323 INFO [MainDeployer] Undeploying file:/C:/usr/JBoss3.2/jboss-3.2/build/output/jboss-3.2 .0RC5/server/default/deploy/hsqldb-ds.xml 20:00:42,323 INFO [HypersonicDatabase] Stopping 20:00:42,603 INFO [HypersonicDatabase] Database closed clean 20:00:42,603 INFO [HypersonicDatabase] Stopped 20:00:42,603 INFO [JBossManagedConnectionPool] Stopping 20:00:42,603 INFO [STDOUT] Tue Apr 01 20:00:42 PST 2003 SHUTDOWN : System.exit() was not called 20:00:42,603 INFO [JBossManagedConnectionPool] Exception destroying ManagedConnection org.jboss.resource.JBossResourceException: SQLException; - nested throwable: (java.sql.SQLException: The database is shutdown in statement [DISCONNECT]) at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.checkExce ption(BaseWrapperMa nagedConnection.java:445) at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.destroy(B aseWrapperManagedCo nnection.java:229) at org.jboss.resource.connectionmanager.InternalManagedConnectionPool.doD estroy(InternalMana gedConnectionPool.java:374) at org.jboss.resource.connectionmanager.InternalManagedConnectionPool.flu sh(InternalManagedC onnectionPool.java:272) at org.jboss.resource.connectionmanager.InternalManagedConnectionPool.shu tdown(InternalManag edConnectionPool.java:307) at org.jboss.resource.connectionmanager.JBossManagedConnectionPool$OnePoo l.shutdown(JBossMan agedConnectionPool.java:675) at org.jboss.resource.connectionmanager.JBossManagedConnectionPool.stopSe rvice(JBossManagedC onnectionPool.java:373) at org.jboss.system.ServiceMBeanSupport.stop(ServiceMBeanSupport.java:236 ) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBean Dispatcher.java:284 ) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControll er.java:966) at $Proxy11.stop(Unknown Source) at org.jboss.system.ServiceController.stop(ServiceController.java:464) at org.jboss.system.ServiceController.stop(ServiceController.java:456) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBean Dispatcher.java:284 ) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177) at $Proxy5.stop(Unknown Source) at org.jboss.deployment.SARDeployer.stop(SARDeployer.java:389) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBean Dispatcher.java:284 ) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.mx.util.JMXInvocationHandler.invoke(JMXInvocationHandler.jav a:177) at $Proxy16.stop
Re: [JBoss-dev] [ jboss-Change Notes-712495 ] Use *-ds.xml files in 3.2 for all jca adapters.
The format of datasource *-ds.xml files hasn't changed. You can now also use tx-connection-manager (etc) tags to deploy any resource adapter. If you want to use the plain mbean deployment descriptors you have to move the ManagedConnectionFactoryName attribute from the connection manager mbean to the pool mbean. Not very pleasant, but 1. I think people should use the *-ds.xml format: this can remain constant even if the underlying mbeans change. 2. better now than later after 3.2 is released. david On 2003.03.31 12:44 Scott M Stark wrote: So if people are using the 3.0 style descriptor or earlier versions of the *-ds.xml descriptor, are they are going to have dependency problems? Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: SourceForge.net [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, March 30, 2003 10:52 PM Subject: [JBoss-dev] [ jboss-Change Notes-712495 ] Use *-ds.xml files in 3.2 for all jca adapters. Change Notes item #712495, was opened at 2003-03-31 06:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=381174aid=712495group_id=22866 Category: None Group: None Status: Open Priority: 5 Submitted By: David Jencks (d_jencks) Assigned to: Nobody/Anonymous (nobody) Summary: Use *-ds.xml files in 3.2 for all jca adapters. Initial Comment: The jca adapter deployment in jboss 3.2 has been extended to allow you to deploy any connection factory for a jca 1.0 adapter using a *-ds.xmol file. Please use these files for all adapters to avoid confusion. The configuration of the underlying mbeans has changed. --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for just $79/mo with 500 GB of bandwidth! No other company gives more support or power for your dedicated server http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: Seeing suprious exception on shutdown in 3.2 now
Oops, I tried to do too many things at once. should be fixed. david On 2003.03.31 14:55 Scott M Stark wrote: The same class is causing an exception on startup as well: 11:53:51,826 INFO [PersistenceManager] Starting 11:53:51,946 INFO [LocalManagedConnectionFactory] exception trying to create exception sorter: java.lang.ClassNotFoundException: org.jboss.resource.adapter.jdbc.vendor.DummyExceptionSorter at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:183) at org.jboss.mx.loading.UnifiedClassLoader.findClass(UnifiedClassLoader.java:401) at java.lang.ClassLoader.loadClass(ClassLoader.java:294) at org.jboss.mx.loading.UnifiedClassLoader.loadClassLocally(UnifiedClassLoader.java:242) at org.jboss.mx.loading.ClassLoadingTask$ThreadTask.run(ClassLoadingTask.java:114) at org.jboss.mx.loading.LoadMgr.nextTask(LoadMgr.java:281) at org.jboss.mx.loading.UnifiedClassLoader3.loadClass(UnifiedClassLoader3.java:181) at java.lang.ClassLoader.loadClass(ClassLoader.java:250) at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnectionFactory.isExceptionFatal(Base WrapperManagedConnectionFactory.java:348) at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.connectionError(BaseWrapperM anagedConnection.java:292) at org.jboss.resource.adapter.jdbc.WrappedConnection.checkException(WrappedConnection.java:8 19) at org.jboss.resource.adapter.jdbc.WrappedStatement.checkException(WrappedStatement.java:767 ) at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedSta tement.java:312) at org.jboss.mq.pm.jdbc2.PersistenceManager.resolveAllUncommitedTXs(PersistenceManager.java: 226) at org.jboss.mq.pm.jdbc2.PersistenceManager.startService(PersistenceManager.java:1299) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:192) 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 org.jboss.system.ServiceController.start(ServiceController.java:408) at org.jboss.system.ServiceController.start(ServiceController.java:408) 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.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177) at $Proxy5.start(Unknown Source) at org.jboss.deployment.SARDeployer.start(SARDeployer.java:241) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:832) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:640) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:613) 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.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177) at $Proxy7.deploy(Unknown Source) at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:404) at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:545) at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeplo ymentScanner.java:195) at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentSca nner.java:268) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:192) 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 $Proxy0.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
Re: [JBoss-dev] Generic ThreadPool in JBoss?
There is the jca 1.5 thread pool, BaseWorkManager. It is a simple implementation of the j2ee 1.4 official thread pool. If this provides more than you want to deal with, lets discuss design. david jencks On 2003.03.29 09:04 Thomas Peuss wrote: Hello! I need a thread pool to simplify my code for the HTTP-loadbalancer. Is there a generic ThreadPool in JBoss-code (HEAD)? Any hints welcome CU Thomas --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] hsqldb options
Prompted by a customer, I did some experiments with hsqldb options. Currently we specify a tcp port and require a hsqldb mbean to start the hsqldb server. This opens a port and requires explicit hsqldb shutdown. Two other options that appear to work are: specify url jdbc:hsqldb:. and remove the hsqldb mbean. This results in a totally in memory db, nothing saved to disk. IMO this is appropriate for most of the testsuite since it eliminates problems with data not being cleaned up between test runs. specify url jdbc:hsqldb:somefile and remove the hsqldb mbean. This results in the db saved in a couple of files named like somefile. No port is opened. No explicit shutdown of hsqldb seems to be required (although I didn't test how much data is actually saved) Could someone who knows more about hsqldb please explain clearly why we would want to continue using the setup we have now rather than one of the tcp-port free options? Thanks david jencks --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Generic ThreadPool in JBoss?
Also, the jca mbean I wrote uses Doug Lea's implementation for the actual pool. david On 2003.03.29 11:59 Scott M Stark wrote: The thread pool needs to be a true mbean service with stats and its configuration exposed via JMX, not just a class. The JCA api and associated component David mentioned should be a good start for such a service. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Bela Ban [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, March 29, 2003 7:59 AM Subject: Re: [JBoss-dev] Generic ThreadPool in JBoss? Thomas Peuss wrote: Hello! I need a thread pool to simplify my code for the HTTP-loadbalancer. Is there a generic ThreadPool in JBoss-code (HEAD)? I'd go for the concurrent.util (Doug Lea's stuff) thread pool (called PooledExecutor). It will be part of JDK 1.5 (Tiger). -- Bela Ban www.javagroups.com (408) 316-4459 --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] What is the diff between the two xmbean default settings
I think the one that is an attribute of the attribute element is a leftover from the xmbean implementation in Juha's book, later replaced with the default element in the descriptors. david jencks On 2003.03.29 16:41 Scott M Stark wrote: There are two default values in an xmbean attribute declaration, one of which appears to be ignored. For this attribute: attribute access=read-only default=3.14159 descriptionPi is a read-only attribute added at the metadata level for which there is no state in the User2 instance. /description namePi/name typedouble/type descriptors currencyTimeLimit value=-1/ default value=3.14159/ /descriptors /attribute only the default value=3.14159/ in the descriptors results in the attribute having a value that is accessible via a getAttribute call on the mbean server. What is the purpose of the default attribute in the attribute element? Scott Stark Chief Technology Officer JBoss Group, LLC --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] 3.2 build broken for a while
tools/etc/xdoclet/templates/mbean-custom.xdt david On 2003.03.22 15:44 Scott M Stark wrote: The removal of the logging from jmx and switching of dependency ordering between common and jmx has broken the build until this is resolved. One complication in doing this is the fact that the xdoclet generated mbeans are referencing a org.jboss.util.jmx.ObjectNameFactory: public static final javax.management.ObjectName OBJECT_NAME = org.jboss.util.jmx.ObjectNameFactory.create(jboss:type=Service,service=ClasspathExtension); Where is this code at so that this can be updated to org.jboss.mx.util.ObjectNameFactory? Scott Stark Chief Technology Officer JBoss Group, LLC --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jboss.net xdoclet subtask
At least the copy in HEAD is actually for xdoclet 1.2. When I migrated HEAD to xdoclet 1.2 I basically ignored the jboss.net xdoclet task. I'd say if the testsuite is OK, it is safe to ignore and let the jboss.net folks fix if there is a problem later. thanks david jencks On 2003.03.20 17:44 Stephen Coy wrote: Hi, Is it reasonable to assume that the jboss.net xdoclet subtask that was being worked on nearly a year ago is currently not used in anger anywhere? I can see a couple of flavours of the code (in org.jboss.net.xdoclet and also thirdparty/xdoclet/jboss.net) in Branch_3_2, but I can't see any actual uses of it in build files. Th reason I ask is that I'm currently migrating Branch_3_2 to xdoclet 1.2, and I'm not sure what to do with the jboss.net stuff. Steve Coy --- This SF.net email is sponsored by: Tablet PC. Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ 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] Where is org.jboss.resource.adapter.jdbc.ExceptionSorter?
On 2003.03.20 13:09 Scott M Stark wrote: Is the org.jboss.resource.adapter.jdbc.ExceptionSorter class supposed to be in jboss-common-jdbc-wrapper.jar? yes. I'll fix this after steve checks in the new xdoclet (I modified my 3.2 copy also). There are several other errors around this also which I'll check in as soon as I get them fixed. david Right now the org.jboss.test.jca.test.ConnectionFactorySerializationUnitTestCase is failing because this class does not exist in any jar/sar/rar from the jca module as far as I can see. 09:41:31,984 INFO [MainDeployer] Deployed package: file:/C:/cvs/JBoss3.2/jboss-3.2/testsuite/output/lib/jcatest.jar 09:41:32,187 ERROR [LogInterceptor] Unexpected Error: java.lang.NoClassDefFoundError: Lorg/jboss/resource/adapter/jdbc/ExceptionSorter; at java.lang.Class.getFields0(Native Method) at java.lang.Class.getDeclaredFields(Class.java:993) at java.io.ObjectStreamClass$1.run(ObjectStreamClass.java:335) at java.security.AccessController.doPrivileged(Native Method) at java.io.ObjectStreamClass.init(ObjectStreamClass.java:288) at java.io.ObjectStreamClass.lookupInternal(ObjectStreamClass.java:107) at java.io.ObjectStreamClass.lookup(ObjectStreamClass.java:54) at java.io.ObjectStreamClass.lookupInternal(ObjectStreamClass.java:83) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:286) at java.io.ObjectOutputStream.outputClassFields(ObjectOutputStream.java:1822) at java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:475) at java.io.ObjectOutputStream.outputObject(ObjectOutputStream.java:1209) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:361) at java.rmi.MarshalledObject.init(MarshalledObject.java:90) at org.jboss.test.jca.ejb.ConnectionFactorySerializationTestSessionBean.testConnectionFactorySerialization(ConnectionFactorySeria lizationTestS essionBean.java:62) Scott Stark Chief Technology Officer JBoss Group, LLC --- This SF.net email is sponsored by: Tablet PC. Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Tablet PC. Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Going ahead with EJB module refactor
I committed the patch to xdoclet and committed a new version of xdoclet to jboss thirdparty. Haven't ruined my mac xx tried updating my jdk yet so jboss continues to build fine for me :-)) david On 2003.03.13 13:41 Dain Sundstrom wrote: So how is it coming? -dain On Wednesday, March 12, 2003, at 06:02 PM, Stephen Coy wrote: The fix certainly allows xdoclet to build itself, whereas it was failing with the same problem we have in JBoss HEAD. I can't check against JBoss HEAD until I get home tonight (its AM here), but I'm a happy camper for my dev work now. Steve Coy On Thursday, March 13, 2003, at 04:15 AM, David Jencks wrote: There's a patch on their bugtracker that is supposed to fix this: http://opensource.atlassian.com/projects/xdoclet/secure/ ViewIssue.jspa?key=XDT-376 They want feedback. I need to keep working so I haven't up(?)graded my 1.4.1 copy yet. david jencks On 2003.03.12 04:53 Jason Dillon wrote: Actually now that I think about it I have to wait until i can actually build the source tree again... Any word from the XDoclet folks on what the problem is? --jason On Wednesday, March 12, 2003, at 03:30 PM, Jason Dillon wrote: Tonight I will be working on the EJB module re-factoring. Will probably have something ready to check in tomorrow. If you have EJB related bits to commit in system please do so now. --jason --- This SF.net email is sponsored by:Crypto Challenge is now open!Get cracking and register here for some mind boggling fun andthe chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] mbean dtd?
These are xmbean dtds, which don't know anything about deployment via *-service.xml files; they describe the structure of the xmbean xml descriptor. The xmbean.dtd is totally obsolete and should not be used IMO and the 3.2 copy of jboss_xmbean_1_0.dtd is almost certainly seriously out of date with the cvs head (jb4) copy. we do not have a dtd for *-service files because attributes can have xml element values. AFAIK the only way to cater to this is with namespaces and xml schema. We may need to do this for jboss 4. basically... depends optional-attribute-name=foo[object name or another mbean dd]/depends and depends-list optional-attribute-name=bar depends-list-element[o-n or mbean dd]/depends-list-element depends-list-element[o-n or mbean dd]/depends-list-element ... /depends-list david jencks On 2003.03.13 17:14 Melissa Turner wrote: Is there a current (3.2) dtd for mbeans? ./jmx/src/main/test/implementation/modelmbean/support/xml/ jboss_xmbean_1_0.dtd and ./jmx/src/main/test/implementation/modelmbean/support/xml/xmbean.dtd Seem to be missing a few things - like nested mbeans and dependencies. +Melissa --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Going ahead with EJB module refactor
There's a patch on their bugtracker that is supposed to fix this: http://opensource.atlassian.com/projects/xdoclet/secure/ViewIssue.jspa?key=XDT-376 They want feedback. I need to keep working so I haven't up(?)graded my 1.4.1 copy yet. david jencks On 2003.03.12 04:53 Jason Dillon wrote: Actually now that I think about it I have to wait until i can actually build the source tree again... Any word from the XDoclet folks on what the problem is? --jason On Wednesday, March 12, 2003, at 03:30 PM, Jason Dillon wrote: Tonight I will be working on the EJB module re-factoring. Will probably have something ready to check in tomorrow. If you have EJB related bits to commit in system please do so now. --jason --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Proposal for jboss-wide interceptor framework
On 2003.03.09 15:20 Bill Burke wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David Jencks Sent: Saturday, March 08, 2003 8:23 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Proposal for jboss-wide interceptor framework 5. multiple interceptor chains per InvocationFactory, e.g. each method gets a separate interceptor chain. (Idea from current mbean interceptor implementation) Do we really need per method interceptor chains? We did not need them to implement EJBs. After working with them a little bit with mbeans for jca 1.5 deployment, I conclude Yes, we absolutely need per-method interceptor chains!! they make life so much simpler I can't believe it. What are you planning to use? The AOP framework as is can only define interception for Java classes and Dynamic Proxies. If you need MBean interception, it is not there unless you want to use the Java class interception. Or, if you want a DP you'll have to change how MBeans are registered with the server. I'm less convinced that relying on a fixed sequence of interceptor factories to generate every chain is the best design. I implemented a quick and dirty way of generating custom chains by simply looking in the mbean metadata for a list of interceptor classes. This strikes me as a lot more convenient for my purposes than having to construct some long interceptor factory list that can be used for any chain. I think generating the interceptor chains needs some more thought. Can you explain what you mean by chain? You're thinking a chain for each method? You're saying its easier to define a chain for each method rather than to define a chain for the whole object? definitely. Why can't we have both? There's no reason why not. sure, this is fine, my proposed interceptor design should let you do this easily. I don't quite see how to fit it into your current aop stuff easily. For the moment I am just using the jmx interceptors and they are working fine. One of my points here is that I think the purpose of the InterceptorFilter is to simulate per-method chains (based on the comment we should cache the results of calling the filter), and I think actual per-method chains are a much clearer and cleaner implementation. Certainly the current implementation of InvocationFilter is silly, all it does is make 2 method calls instead of one. Bill, my impression is that you are planning to use your AOP framework as-is for the ejb conversion. Is there anything I can do to influence you towards using per-method interceptors from the start? Or do you think two smaller rewrites is a better plan than one larger rewrite? No where in our entire EJB/J2EE codebase do we use per-method interceptors. Jmx has had per method interceptors for many months. I'm just putting them to use. The use of the AOP Invocation object nor the Interceptor interface effects configuration or whether or not there are method chains or not. ?? Can't decipher what you are trying to say here. Thanks david Bill --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed
Does this change prevent us from writing a remote jndi implementation that runs over the remoting framework? If so, is this the direction we want to go in? david jencks On 2003.03.07 03:10 Tom Elrod wrote: Build fixed now. Please note that naming is now part of core modules. This is due to remoting now requiring naming, since the addition of a JNDI detector. -Tom -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Tom Elrod Sent: Friday, March 07, 2003 2:55 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed I did this while in process of doing checkin. Should be fixed in a minute. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: Friday, March 07, 2003 2:34 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed = ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net FOR DETAILS= = JAVA VERSION DETAILS java version 1.3.1_06 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_06-b01) Java HotSpot(TM) Server VM (build 1.3.1_06-b01, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE [mkdir] Created dir: /home/jboss/jbossci/jboss-head/remoting/output/classes [mkdir] Created dir: /home/jboss/jbossci/jboss-head/remoting/output/gen/classes [depend] Deleted 0 out of date files in 0 seconds [javac] Compiling 62 source files to /home/jboss/jbossci/jboss-head/remoting/output/classes /home/jboss/jbossci/jboss-head/remoting/src/main/org/jboss/rem oting/detection/jndi/JNDIDetector.java:19: cannot resolve symbol symbol : class NamingContextFactory location: package interfaces import org.jnp.interfaces.NamingContextFactory; ^ /home/jboss/jbossci/jboss-head/remoting/src/main/org/jboss/rem oting/detection/jndi/JNDIDetector.java:20: cannot resolve symbol symbol : class Main location: package server import org.jnp.server.Main; ^ /home/jboss/jbossci/jboss-head/remoting/src/main/test/detectio n/jndi/JNDIDetectorTest.java:15: cannot resolve symbol symbol : class Main location: package server import org.jnp.server.Main; ^ /home/jboss/jbossci/jboss-head/remoting/src/main/org/jboss/rem oting/detection/jndi/JNDIDetector.java:365: cannot resolve symbol symbol : class Main location: class org.jboss.remoting.detection.jndi.JNDIDetector Main server = new Main(); ^ /home/jboss/jbossci/jboss-head/remoting/src/main/org/jboss/rem oting/detection/jndi/JNDIDetector.java:365: cannot resolve symbol symbol : class Main location: class org.jboss.remoting.detection.jndi.JNDIDetector Main server = new Main(); ^ /home/jboss/jbossci/jboss-head/remoting/src/main/org/jboss/rem oting/detection/jndi/JNDIDetector.java:370: cannot resolve symbol symbol : class NamingContextFactory location: class org.jboss.remoting.detection.jndi.JNDIDetector contextFactory = NamingContextFactory.class.getName(); ^ /home/jboss/jbossci/jboss-head/remoting/src/main/test/detectio n/jndi/JNDIDetectorTest.java:57: cannot resolve symbol symbol : class Main location: class test.detection.jndi.JNDIDetectorTest Main JNDIServer = new Main(); ^ /home/jboss/jbossci/jboss-head/remoting/src/main/test/detectio n/jndi/JNDIDetectorTest.java:57: cannot resolve symbol symbol : class Main location: class test.detection.jndi.JNDIDetectorTest Main JNDIServer = new Main(); ^ 8 errors BUILD FAILED file:/home/jboss/jbossci/jboss-head/remoting/../tools/etc/buil dfragments/targets.ent:45: Compile failed; see the compiler error output for details. Total time: 23 seconds --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Etnus, makers
Re: [JBoss-dev] Support for application clients
Or maybe noone has implemented it. Every now and again someone asks. Unless it can be done really easily I'm not in favor of trying to add this to jb3.2. I think it can be done really easily in jb4 since we are (or will be) starting a jmx mbean server in the client so we can easily make the app client support using mbeans. I suspect the jmx remoting will also be useful. Are you interested in implementing it? david jencks On 2003.03.04 11:24 Igor Fedorenko wrote: Hi, JBoss 3.2 does not seem to support application clients as specified in J2EE Spec, v1.3, section 9. Is there any reason why this is not supported other than nobody has asked it? Igor Fedorenko Think smart. Think automated. Think Dynamics. www.thinkdynamics.com --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] 3.2 testsuite will not build under 1.3
This code has been compiling in your test runs under jdk 1.3.1 for both 3.0 and 3.2 for 2 weeks. Can you check the contents of jboss-jca.sar to see if Savepoint is in it? I believe prior to Jasons build speed up change a couple of days ago this contained Savepoint and the other jdk 1.4 java classes. Perhaps the change in buildfile structure changed which properties are getting set when and caused these files to be left out of the sar. thanks david jencks On 2003.03.04 20:13 Scott M Stark wrote: The 3.2 testsuite is not building under JDK 1.3 due to the inclusion of the java.sql.Savepoint class: [javac] C:\cvs\JBoss3.2\jboss-3.2\testsuite\src\main\org\jboss\test\jca\jdbc \TestConnection.java:18: cannot resolve symbol [javac] symbol : class Savepoint [javac] location: package sql [javac] import java.sql.Savepoint; [javac] ^ [javac] C:\cvs\JBoss3.2\jboss-3.2\testsuite\src\main\org\jboss\test\jca\jdbc \TestConnection.java:223: cannot resolve symbol [javac] symbol : class Savepoint [javac] location: class org.jboss.test.jca.jdbc.TestConnection [javac]public Savepoint setSavepoint() [javac] ^ [javac] C:\cvs\JBoss3.2\jboss-3.2\testsuite\src\main\org\jboss\test\jca\jdbc \TestConnection.java:228: cannot resolve symbol [javac] symbol : class Savepoint [javac] location: class org.jboss.test.jca.jdbc.TestConnection [javac]public Savepoint setSavepoint(String name) [javac] ^ [javac] C:\cvs\JBoss3.2\jboss-3.2\testsuite\src\main\org\jboss\test\jca\jdbc \TestConnection.java:233: cannot resolve symbol [javac] symbol : class Savepoint [javac] location: class org.jboss.test.jca.jdbc.TestConnection [javac]public void rollback(Savepoint s) [javac] ^ [javac] C:\cvs\JBoss3.2\jboss-3.2\testsuite\src\main\org\jboss\test\jca\jdbc \TestConnection.java:236: cannot resolve symbol [javac] symbol : class Savepoint [javac] location: class org.jboss.test.jca.jdbc.TestConnection [javac]public void commit(Savepoint s) [javac] ^ [javac] C:\cvs\JBoss3.2\jboss-3.2\testsuite\src\main\org\jboss\test\jca\jdbc \TestConnection.java:240: cannot resolve symbol [javac] symbol : class Savepoint [javac] location: class org.jboss.test.jca.jdbc.TestConnection [javac]public void releaseSavepoint(Savepoint s) Scott Stark Chief Technology Officer JBoss Group, LLC --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] 3.2 testsuite will not build under 1.3
On 2003.03.04 21:30 Scott M Stark wrote: No, its not there: testsuite 125jar -tf ../connector/output/lib/jboss-jca.sar | grep Save testsuite 126 All Jason's changes were on main, not 3.2. Looking further into the issue I see the tree was built with JDK 1.4.1 and the testsuite was trying to build with JDK 1.3.1 and this does not work because the 1.4.1 classes are not included in jboss-jca.sar. Maybe another reason to drop 1.3 for the 4.0 release. Yes, jason's changes were only on head. Are you saying that in the failed test run jboss was built on 1.4.1 but the testsuite was built on 1.3? This definitely won't work with the current connector build. Building both with 1.3 or both with 1.4.1 should work. david Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, March 04, 2003 6:18 PM Subject: Re: [JBoss-dev] 3.2 testsuite will not build under 1.3 This code has been compiling in your test runs under jdk 1.3.1 for both 3.0 and 3.2 for 2 weeks. Can you check the contents of jboss-jca.sar to see if Savepoint is in it? I believe prior to Jasons build speed up change a couple of days ago this contained Savepoint and the other jdk 1.4 java classes. Perhaps the change in buildfile structure changed which properties are getting set when and caused these files to be left out of the sar. thanks david jencks --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed
I don't think so, the error is not shown. I built fresh from a clean checkout last night with no problems. The problem may be that Chris is not doing a clean checkout every day. david jencks On 2003.03.03 09:41 Bill Burke wrote: Is this an XDoclet thing again? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: Sunday, March 02, 2003 8:41 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [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
Re: Re[2]: [JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed
Would it be possible for someone who knows/has both windows and linux scripting to investigate this? I recall that I had to increase the memory for the build in the build.sh files and I don't know if this was ever done in the build.bat files. thanks david jencks On 2003.03.03 10:34 Alex Loubyansky wrote: This morning I had problems with this error and clean build. The error was out of memory. JDK 1.3.1_05 Windows2000 alex Monday, March 03, 2003, 5:06:03 PM, David Jencks wrote: DJ I don't think so, the error is not shown. DJ I built fresh from a clean checkout last night with no problems. The DJ problem may be that Chris is not doing a clean checkout every day. DJ david jencks DJ On 2003.03.03 09:41 Bill Burke wrote: Is this an XDoclet thing again? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: Sunday, March 02, 2003 8:41 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [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
RE: [JBoss-dev] Proposal for jboss-wide interceptor framework
On 2003.03.02 16:16 Nathan Phelps wrote: I agree. With what, specifically? As I begin the development of JMS/JBoss 4.0, I'm, frankly, confused as to which direction to go concerning the interceptor framework--which project is THE project? There is some great work being done right now by a variety of people on this problem, but I have no idea how it all fits together--if it fits together. I wish we could settle this problem, agree on which direction we are going, and then get the code base stabilized so those of us building services that will use THE framework can have the confidence that we're working with the right one and that it works as advertised. Well, before my contribution we had at least 4 incompatible interceptor models and a lot of lip service about eventually merging them. To me it is clear that we could make any of the existing models work everywhere. Interceptors are not rocket science. Unifying them is primarily an exercise in agreeing on which features we want. Since my initial attempt to start discussion on this topic has only provoked wails of dismay from people who have not recently implemented interceptor models in jboss and no response from those who have, I'll try to explain the features I have attempted to include. 1. Source located in neutral territory, namely the common module. 2. Sequence of interceptors determined by (iterator in) invocation object. 3. Construction of interceptors through interceptor factories. 4. Storing interceptor specific metadata in the invocation factory (e.g. for ejbs, this is the currently the Container). This makes it easy to write stateless interceptors. 5. multiple interceptor chains per InvocationFactory, e.g. each method gets a separate interceptor chain. (Idea from current mbean interceptor implementation) 6. Ability to replace the interceptor interator. This is not directly supported now but is essentially what happens when an invocation goes from the client interceptor stack to the invoker interceptor stack. (Currently the only example of an invoker interceptor stack is the trunk invoker.) I'd really appreciate review of my proposed implementation by Bill, Juha, Dain, and Jeff (and anyone else who has worked on interceptor design that I'm not aware of). In particular I suspect the serialization support will need fairly extensive modification to fit with the remoting framework. I think of my proposal as pretty much based on Bill's aop interceptor design with primarily stylistic changes (and the method specific interceptor chains from mbeans). All comments on the proposal's design and implementation welcome. Like Nathan, I want the question of what interceptor framework we are going to use to be settled soon since both the dtm and deployment of jca 1.5 adapters depend on it. I'm not really interested in developing these features twice for two different models. thanks david jencks Thanks, Nathan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott M Stark Sent: Sunday, March 02, 2003 1:37 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Proposal for jboss-wide interceptor framework Woa, before we have a full fledged interceptor war show up in main what is the status of the various JMX, AOP, etc interceptors and associated frameworks? It seems like several people are running around writing this without demonstrating how it applies to the existing services. A simple example is how do I expose the existing JNDI naming service via RMI/JRMP and RMI/HTTP with that ability to introduce security and persistence? Scott Stark Chief Technology Officer JBoss Group, LLC --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- 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] Proposal for jboss-wide interceptor framework
First, thanks for responding. On 2003.03.03 15:29 Bill Burke wrote: -Original Message- From: David Jencks [mailto:[EMAIL PROTECTED] Sent: Monday, March 03, 2003 2:17 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Proposal for jboss-wide interceptor framework On 2003.03.02 16:16 Nathan Phelps wrote: I agree. With what, specifically? As I begin the development of JMS/JBoss 4.0, I'm, frankly, confused as to which direction to go concerning the interceptor framework--which project is THE project? There is some great work being done right now by a variety of people on this problem, but I have no idea how it all fits together--if it fits together. I wish we could settle this problem, agree on which direction we are going, and then get the code base stabilized so those of us building services that will use THE framework can have the confidence that we're working with the right one and that it works as advertised. Well, before my contribution we had at least 4 incompatible interceptor models and a lot of lip service about eventually merging them. To me it is clear that we could make any of the existing models work everywhere. Interceptors are not rocket science. Unifying them is primarily an exercise in agreeing on which features we want. Since my initial attempt to start discussion on this topic has only provoked wails of dismay from people who have not recently implemented interceptor models in jboss and no response from those who have, I'll try to explain the features I have attempted to include. 1. Source located in neutral territory, namely the common module. 2. Sequence of interceptors determined by (iterator in) invocation object. 3. Construction of interceptors through interceptor factories. 4. Storing interceptor specific metadata in the invocation factory (e.g. for ejbs, this is the currently the Container). This makes it easy to write stateless interceptors. Metadata should be in 2 places. The class or invocation factory, and the actual instance. I keep your design for list of metadatas: however I gave the InvocationFactory and additional SimpleMetadata that the InterceptorFactories can use to put metadata in, and I put it at the end of the list of metadatas so it can be overridden. 5. multiple interceptor chains per InvocationFactory, e.g. each method gets a separate interceptor chain. (Idea from current mbean interceptor implementation) Do we really need per method interceptor chains? We did not need them to implement EJBs. Juha thought they were a good enough idea to implement them for mbeans. You put in interceptor filters, and I think multiple chains is better way of implementing the same idea. Lastly, they can avoid a lot of confusing conditional logic in an interceptor: the TxSupport class is really designed to be a set of method-specific interceptors so you don't need a method to txsupport map. 6. Ability to replace the interceptor interator. This is not directly supported now but is essentially what happens when an invocation goes from the client interceptor stack to the invoker interceptor stack. (Currently the only example of an invoker interceptor stack is the trunk invoker.) Not sure what you mean by replacement. Do you mean hot-deploy of new interceptors? I have this now in AOP framework for POJOs. No. A typical ejb remote call needs to go through 4 interceptor stacks: client interceptors, client side transport interceptors (HA sprayer and InvokerXAResource anyway), server side transport interceptors (no examples yet, waiting for this to stabilize a bit) and the server side ejb interceptors. AFAIK we can either replace the interceptor iterator at each junction or construct a new Invocation object. I thought it would be simpler to replace the interceptor iterator. Hot deploy of new interceptors seems pretty cool. I'll have to look at how you do it. david I'd really appreciate review of my proposed implementation by Bill, Juha, Dain, and Jeff (and anyone else who has worked on interceptor design that I'm not aware of). In particular I suspect the serialization support will need fairly extensive modification to fit with the remoting framework. If we go the DP route, I don't think serialization is much of a problem since we've already figured most of this out with EJBs. well, we now have about 2 implementations, the ejb one and the remoting framework one. I think the remoting framework one has a lot more features and I thought we basically agreed to use it. So the work is figuring out how to use ejbs with it. What we DO have to implement is a generic reference object. For instance, a reference to an EJB, MBean, whatever. This is needed so that the transport mechanism can marshall
Re: [JBoss-dev] WTF happened to XDoclet tool config?!
Well, I hope you can fix this Jason because I couldn't, and I'm about 98% sure the problems lie in the buildmagic extensions being incompatible with current versions of ant. We have a long term goal of moving the jboss related xdoclet support to jboss cvs. I attempted to start this and to make constructing an appropriate xdoclet version for use in the jboss build an automated process by building xdoclet in the jboss build process. Thus, the xdoclet module attempts to check xdoclet out of xdoclet cvs and build it. So far so good, but it is impossible to build the rest of jboss using the just built xdoclet. For a while I was able to build by trying twice, the second attempt succeeded, but this did not seem to work reliably. The really odd thing was that the parts that could not be found had just been used for one or two module builds! After struggling for a week or so I gave up and made a simple mechanism to check the results of the xdoclet build into cvs thirdparty. BTW having xdoclet in tools/lib will obviously not work if xdoclet is built as part of the jboss build. In general I believe ant recommends not putting jars in tools/lib but defining your tasks using an explicit classpath. The build failures seemed to occur mostly because some part that had been compiled earlier in the build process were not available later in the build process. I just found another possibly similar example of this behavior that is possibly more serious. On a clean checkout, executing the main build module tests target will not build very many modules before stopping, being unable to find a module it just built. Running ./build.sh, then ./build.sh tests seems to work. (The build tests target builds each module, runs module-level unit tests, and finally starts jboss and runs the testsuite. The output from module level unit tests is included in the test reports.) My feeling after struggling with these problems is that the buildmagic build organization is the best part of the jboss build system, but that we should try to eliminate the buildmagic tasks if at all possible in favor of standard ant. I don't think anyone here wants to spend their time working on ant tasks. Ant demonstrated a long time ago that they do not preserve backward compatibility with external tasks, and we demonstrated that we don't keep up. (originally build/build.sh clean main worked, but it stopped working a really long time ago: the order of the modules is confused in the main target). Thanks david jencks On 2003.03.02 03:43 Jason Dillon wrote: What happened to the XDoclet tool configuration? I don't get it... we went from simply including the required jars in tools/lib (IMO the way it should be) to including it from thirdparty (which has just been a pain) and now there is some jboss-xdoclet pseudo module which does who knows what. So what is the deal? This has complicated the already over complicated build system. Can someone please explain the reasoning behind this. I am sure there was a good reason, but I am even more sure that there is a less intrusive and simpler way to go about getting the same effect. --jason --- 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] WTF happened to XDoclet tool config?!
On 2003.03.02 08:44 Jason Dillon wrote: I would like to eliminate the buildmagic tasks too. Right now I am looking into using Maven to replace it all. If I get something running with Maven I will try to add an XDoclet module as a depend to allow other projects to use the built tasks... not sure how well that will work just yet though. Unfortunately the changes made broke other projects (like buildmagic, though I believe that project is hosed in other ways too). Lastly I am not sure that we really want to pull xdoclet from its cvs each build. Can you provide me with more details as to what we want to achieve please. The primary overall goal is to move the xdoclet jboss module into jboss cvs. A secondary goal is to be able to build a jboss specific version of xdoclet core, since changes to the jboss-specific stuff have often required bugfixes or implementation of missing functionality to xdoclet core. I started with the secondary goal. The build system is set up so that xdoclet will only be built once unless you manually delete some tag files (last.xdoclet.update and last.xdoclet.build) I know Maven has some kind of repository idea. Is there some way we can combine this with our need to use unreleased builds of e.g. xdoclet? Many many thanks for looking into this david Thanks, --jason On Sunday, March 2, 2003, at 08:09 PM, David Jencks wrote: Well, I hope you can fix this Jason because I couldn't, and I'm about 98% sure the problems lie in the buildmagic extensions being incompatible with current versions of ant. We have a long term goal of moving the jboss related xdoclet support to jboss cvs. I attempted to start this and to make constructing an appropriate xdoclet version for use in the jboss build an automated process by building xdoclet in the jboss build process. Thus, the xdoclet module attempts to check xdoclet out of xdoclet cvs and build it. So far so good, but it is impossible to build the rest of jboss using the just built xdoclet. For a while I was able to build by trying twice, the second attempt succeeded, but this did not seem to work reliably. The really odd thing was that the parts that could not be found had just been used for one or two module builds! After struggling for a week or so I gave up and made a simple mechanism to check the results of the xdoclet build into cvs thirdparty. BTW having xdoclet in tools/lib will obviously not work if xdoclet is built as part of the jboss build. In general I believe ant recommends not putting jars in tools/lib but defining your tasks using an explicit classpath. The build failures seemed to occur mostly because some part that had been compiled earlier in the build process were not available later in the build process. I just found another possibly similar example of this behavior that is possibly more serious. On a clean checkout, executing the main build module tests target will not build very many modules before stopping, being unable to find a module it just built. Running ./build.sh, then ./build.sh tests seems to work. (The build tests target builds each module, runs module-level unit tests, and finally starts jboss and runs the testsuite. The output from module level unit tests is included in the test reports.) My feeling after struggling with these problems is that the buildmagic build organization is the best part of the jboss build system, but that we should try to eliminate the buildmagic tasks if at all possible in favor of standard ant. I don't think anyone here wants to spend their time working on ant tasks. Ant demonstrated a long time ago that they do not preserve backward compatibility with external tasks, and we demonstrated that we don't keep up. (originally build/build.sh clean main worked, but it stopped working a really long time ago: the order of the modules is confused in the main target). Thanks david jencks On 2003.03.02 03:43 Jason Dillon wrote: What happened to the XDoclet tool configuration? I don't get it... we went from simply including the required jars in tools/lib (IMO the way it should be) to including it from thirdparty (which has just been a pain) and now there is some jboss-xdoclet pseudo module which does who knows what. So what is the deal? This has complicated the already over complicated build system. Can someone please explain the reasoning behind this. I am sure there was a good reason, but I am even more sure that there is a less intrusive and simpler way to go about getting the same effect. --jason --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list
[JBoss-dev] New module for cmp? What about the ejb module?
Would it be appropriate to put the new cmp framework in its own module since it is not particularly dependent on ejbs? Are we going to move the ejb support into the currently empty ejb module? david jencks --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Proposal for jboss-wide interceptor framework
(resending, first attempt seems to have disappeared) I've committed a proposal for a jboss-wide interceptor framework in the common module under org.jboss.interception. This is based on Bill's aop interceptor framework. It compiles but is untested. Several more or less needed features are not yet implemented, such as a convenient way to supply a list of InterceptorFactories. The main differences, aside from coding style, are 1. I provide explicit support for changing the interceptor iterator as a part of the invocation. For instance, this would be used when going from the proxy-specific client interceptor chain to the transport specific interceptor chain, be reset upon deserialization by the server-side transport mechanism endpoint, and be reset when going from the server-side transport specific interceptor chain to the e.g. ejb interceptor chain. 2. I provide explicit support for overridable interceptor specific metadata set up by the InterceptorFactory. For instance, for an interceptor that uses ejb xml metadata, the InterceptorFactory would process the xml into a more appropriate form for use by the interceptor and store it in this metadata using the interceptor instance as a key. The interceptor can then retrieve the metadata using itself as a key. I believe both Dain and I prototyped ejb interceptor implementations using this mechanism and were pleased with the code simplifications that resulted. This metadata is stored in the InvocationFactory and supplied last to the list of metadata resolvers in each invocation. This allows overriding by earlier metadata in the list of resolvers. 3. I provide a framework for method (or field, etc etc) specific interceptor chains. The InvocationFactory maintains a map of keys to interceptor chains. The key will typically be the method/field/whatever the invocation is for. The chains are constructed from a single list of InterceptorFactories by supplying the key. If the interceptor is not needed for a particular key, the InterceptorFactory returns null. This replaces the InterceptorFilterFactory interface. And finally a question... I think it would be more appropriate to have single level metadata rather than the 2-level scheme Bill has implemented. The 2 level scheme can be easily recovered by those interceptors that want it by storing a (single-level) SimpleMetaData object as the first level metadata object. This would make it easier for interceptors to store individual custom objects as their metadata. I'd appreciate any and all comments especially if they are soon. If there is no strong opposition I will start working to convert the remoting framework, client interceptors, and mbean interceptors to use this framework. Many thanks david jencks --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Proposal for jboss-wide interceptor framework.
I've committed a proposal for a jboss-wide interceptor framework in the common module under org.jboss.interception. This is based on Bill's aop interceptor framework. It compiles but is untested. Several more or less needed features are not yet implemented, such as a convenient way to supply a list of InterceptorFactories. The main differences, aside from coding style, are 1. I provide explicit support for changing the interceptor iterator as a part of the invocation. For instance, this would be used when going from the proxy-specific client interceptor chain to the transport specific interceptor chain, be reset upon deserialization by the server-side transport mechanism endpoint, and be reset when going from the server-side transport specific interceptor chain to the e.g. ejb interceptor chain. 2. I provide explicit support for overridable interceptor specific metadata set up by the InterceptorFactory. For instance, for an interceptor that uses ejb xml metadata, the InterceptorFactory would process the xml into a more appropriate form for use by the interceptor and store it in this metadata using the interceptor instance as a key. The interceptor can then retrieve the metadata using itself as a key. I believe both Dain and I prototyped ejb interceptor implementations using this mechanism and were pleased with the code simplifications that resulted. This metadata is stored in the InvocationFactory and supplied last to the list of metadata resolvers in each invocation. This allows overriding by earlier metadata in the list of resolvers. 3. I provide a framework for method (or field, etc etc) specific interceptor chains. The InvocationFactory maintains a map of keys to interceptor chains. The key will typically be the method/field/whatever the invocation is for. The chains are constructed from a single list of InterceptorFactories by supplying the key. If the interceptor is not needed for a particular key, the InterceptorFactory returns null. This replaces the InterceptorFilterFactory interface. And finally a question... I think it would be more appropriate to have single level metadata rather than the 2-level scheme Bill has implemented. The 2 level scheme can be easily recovered by those interceptors that want it by storing a (single-level) SimpleMetaData object as the first level metadata object. This would make it easier for interceptors to store individual custom objects as their metadata. I'd appreciate any and all comments especially if they are soon. If there is no strong opposition I will start working to convert the remoting framework, client interceptors, and mbean interceptors to use this framework. Many thanks david jencks --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Proposal for jboss-wide interceptor framework
No No!! War War War!!! :-)) Actually I just wanted to get the discussion started early on and try to get people involved since I think it will be a big undertaking to convert all the interceptor models to a single one. I don't want to spring an entire system conversion on anyone without a lot of warning. I don't see how your proposed example is simple since I think it involves at least converting the remoting framework and probably the aop stuff. I was thinking of working in this order: mbeans remoting client interceptors ejb interceptors other. Aop could be converted at any time Bill agrees: I think this model is close enough to his that this conversion should be fairly easy. I think the main difference is the per-method interceptor stacks, which can probably be not used at first. mbeans should also be fairly easy since I think this model is also close to the mbean interceptor one. thanks david On 2003.03.02 14:36 Scott M Stark wrote: Woa, before we have a full fledged interceptor war show up in main what is the status of the various JMX, AOP, etc interceptors and associated frameworks? It seems like several people are running around writing this without demonstrating how it applies to the existing services. A simple example is how do I expose the existing JNDI naming service via RMI/JRMP and RMI/HTTP with that ability to introduce security and persistence? Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, March 02, 2003 10:28 AM Subject: [JBoss-dev] Proposal for jboss-wide interceptor framework (resending, first attempt seems to have disappeared) I've committed a proposal for a jboss-wide interceptor framework in the common module under org.jboss.interception. This is based on Bill's aop interceptor framework. It compiles but is untested. Several more or less needed features are not yet implemented, such as a convenient way to supply a list of InterceptorFactories. The main differences, aside from coding style, are 1. I provide explicit support for changing the interceptor iterator as a part of the invocation. For instance, this would be used when going from the proxy-specific client interceptor chain to the transport specific interceptor chain, be reset upon deserialization by the server-side transport mechanism endpoint, and be reset when going from the server-side transport specific interceptor chain to the e.g. ejb interceptor chain. 2. I provide explicit support for overridable interceptor specific metadata set up by the InterceptorFactory. For instance, for an interceptor that uses ejb xml metadata, the InterceptorFactory would process the xml into a more appropriate form for use by the interceptor and store it in this metadata using the interceptor instance as a key. The interceptor can then retrieve the metadata using itself as a key. I believe both Dain and I prototyped ejb interceptor implementations using this mechanism and were pleased with the code simplifications that resulted. This metadata is stored in the InvocationFactory and supplied last to the list of metadata resolvers in each invocation. This allows overriding by earlier metadata in the list of resolvers. 3. I provide a framework for method (or field, etc etc) specific interceptor chains. The InvocationFactory maintains a map of keys to interceptor chains. The key will typically be the method/field/whatever the invocation is for. The chains are constructed from a single list of InterceptorFactories by supplying the key. If the interceptor is not needed for a particular key, the InterceptorFactory returns null. This replaces the InterceptorFilterFactory interface. And finally a question... I think it would be more appropriate to have single level metadata rather than the 2-level scheme Bill has implemented. The 2 level scheme can be easily recovered by those interceptors that want it by storing a (single-level) SimpleMetaData object as the first level metadata object. This would make it easier for interceptors to store individual custom objects as their metadata. I'd appreciate any and all comments especially if they are soon. If there is no strong opposition I will start working to convert the remoting framework, client interceptors, and mbean interceptors to use this framework. Many thanks david jencks --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RARDeployment - what happened to it?
Sure. The *-ds.xml file gets xsl-transformed into 3 mbeans/datasource, so just pick the ConnectionManager one and depend on it. You can find the exact object name in the jmx-console after you deploy the *-ds.xml file. david On 2003.03.01 11:16 Nolan Wright wrote: Thanks. I was able to get things working by using the *-ds.xml. One question: if I have a service that depends on a data source, is there a way I can specify that dependency? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Jencks Sent: Friday, February 28, 2003 3:43 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] RARDeployment - what happened to it? Not in jb4 you don't, it's been quite rewritten. What exactly are you having problems with? You pretty much need to use the *-ds.xml files with jb4: if you want to use a *-service.xml file to deploy a datasource you need to include an xmbean configuration to deploy the ManagedConnectionFactory inside the *-service.xml which is at best hard to understand for humans. david jencks On 2003.02.28 15:24 Tom Elrod wrote: What happened to the RARDeployment class that was in the org.jboss.resource.connectionmanager package? Needed it for connection pooling in data source xml. --- 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 --- 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] stop using JDK 1.4 for development
I'd prefer to have a reliable way to report these problems, since I don't consider it realistic for me to develop on 1.3.1. How do you detect them? For the particular problem of nested exceptions, I think we should always use the jboss NestedThrowable stuff Jason wrote since it provides a much more reasonable stack trace. Dain and I made as much as we could find of the jca and jta frameworks use this with good results. How could we make this better known and popularize it? thanks david jencks On 2003.02.28 08:42 Bill Burke wrote: There have been a lot of build breakages lately because people are using JDK 1.4 features and they break in JDK 1.3 builds. WE STILL SUPPORT JDK 1.3. My suggestion? Stop developing JBOss with jdk 1.4 and develop with 1.3. Please stop the sloppiness. 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] stop using JDK 1.4 for development
On 2003.02.28 10:23 Jeff Haynie wrote: The problem really is with me - I fess up. Bill's mad because I broke the build twice this week by inadvertantly checking in code (throwing an exception that is the new overloaded version in 1.4) that only compiles on 1.4. Unfortunately, my whole work and home environment *DO* require 1.4 and only works under 1.4 - so I sometimes forget to re-set my path to JDK1.3 when I compile. So, it compiles fine under 1.4. I'm changing my jboss build environment to force my path and JDK to 1.3 before it runs. Maybe be can update the build.bat/.sh to automatically do this (or at least check the version before you compile) and that would fix this problem for everyone? I don't think this is viable, since some features are simply going to be supported only on jdk 1.4. The primary example is working/reasonable transaction logging: I think non-blocking sockets versions of transport will be another example. I really think a reliable warning service is the way to go. I found Chris Kimpton's compilation reports so unreliable I stopped paying attention to them a long time ago. Are they useful to anyone? david -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Jencks Sent: Friday, February 28, 2003 10:16 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] stop using JDK 1.4 for development I'd prefer to have a reliable way to report these problems, since I don't consider it realistic for me to develop on 1.3.1. How do you detect them? For the particular problem of nested exceptions, I think we should always use the jboss NestedThrowable stuff Jason wrote since it provides a much more reasonable stack trace. Dain and I made as much as we could find of the jca and jta frameworks use this with good results. How could we make this better known and popularize it? thanks david jencks On 2003.02.28 08:42 Bill Burke wrote: There have been a lot of build breakages lately because people are using JDK 1.4 features and they break in JDK 1.3 builds. WE STILL SUPPORT JDK 1.3. My suggestion? Stop developing JBOss with jdk 1.4 and develop with 1.3. Please stop the sloppiness. 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 --- 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] RARDeployment - what happened to it?
Not in jb4 you don't, it's been quite rewritten. What exactly are you having problems with? You pretty much need to use the *-ds.xml files with jb4: if you want to use a *-service.xml file to deploy a datasource you need to include an xmbean configuration to deploy the ManagedConnectionFactory inside the *-service.xml which is at best hard to understand for humans. david jencks On 2003.02.28 15:24 Tom Elrod wrote: What happened to the RARDeployment class that was in the org.jboss.resource.connectionmanager package? Needed it for connection pooling in data source xml. --- 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: Directory layout (was Re: [JBoss-dev] JBOSS and SQL Server 2000)
Early in 2.x development we had one module, as you seem to be recommending. Personally I still think we would be developing 2.x level features without the module structure. Among the many advantages modules give you are the ability to know where a feature ends, the ability to easily enforce and document limited dependencies between modules, and the ability to have module-level unit tests. We aren't taking very good advantage of most of these, but IMNSHO the extent we have has made development of jboss 3 and 4 conceivable. I think most of the problems you mention are due to incomplete modularization of the original 2.2 or so project. For instance, just now am I removing the last extraneous bits of the tm from the server module (and only in jb4). The other project I have worked with that has adopted a modularized structure similar to jboss has experienced similar gains in development freedom and maintainability. david jencks On 2003.02.27 17:00 Dave Neuer wrote: --- Dain Sundstrom [EMAIL PROTECTED] wrote: snip I agree about the eclipse discussion, but it does actually have a point for development of the jboss server. It is always a pain to get any IDE to like our directory layout. -dain I would go so far as to say that it is a pain to get a potential new developer to like the directory layout as well, and that only with a tool like Eclipse is does it even begin to feel feasable to a new developer to navigate the hierarchy of widely dispersed directories (and identically named classes in different packages). Especially assuming that that developer is used to the conventional single package/directory hierarchy used in most Java development shops/projects. While I can see an advantage for the current layout in terms of facilitating working on one small piece of the system, I also think that it adds a great deal of overhead to grasping the JBoss architecture and makes finding other source files/packages that might be relevant more difficult (i.e., find ../../../ -type d 'org/jboss/management' -print). Is there some other advantage that the current layout provides as well? Ant can certainly handle building and packaging up discreet files from a single hierarchy so it's not really a build/packaging issue, right? I could see how one might argue that it makes concurrent experimental development easier (a la Bill-AOP/Hiram-AOP) except that that's what CVS branches are for, right? Sorry if this has been covered on the lists or the forums ad nauseum or if there's consensus that the current layout is the right way. Dave Neuer __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread
On 2003.02.25 02:58 Sacha Labourey wrote: Hello, This discussion is somehow strange because, and I agree with David: you don't seem to be speaking about the same thing at the same time... Asynchronous argumentation is hard to follow... - I think we should have interceptors - Yes, but the sky is blue - No! Invokers can't handle DTM in this case - You mean AOP? I understand David's point of view. David loves orthogonal designs and the idea to have somehow symetric interceptors (between the client and the server), possibly with a null invoker in the middle of the chain makes his design pleaseant. Nevertheless, where I think I agree with Bill is that we first have to check if we don't go too far just for the beauty of it. Let's take IIOP as an example. In the general case, IIOP can only transport the same kind of data: - invocations information (method name, arguments, etc.) - arbitrary context information In the arbitrary payload, you may find security information, transaction information, etc. The question is: at the end of the day, do we really need a stack of interceptors just to extract this set of information and populate a JBoss invocation object? Couldnt we more simply just extract all this stuff and put it in the Invocation Object (and the server side Invoker could do that). I agree, it would look much smarter to have this separation of concern and have each interceptor from a virtual-client-stack (i.e. client side interceptors living on the server and mimic-ing client-side behaviour) put only what is needed inside the JBoss invocation object. NEVERTHELESS, as this information will always be similar, why not simply do that in a generic way inside the invoker: in-mass population of the invocation with well-known key names for well-known invocation content. If you think about it, the invoker already does that: it extracts the target MBean ObjectName from the invocation and push the invocation to it: if you push your reasoning far enough, that's already a concern that shouldn't be put in a pure transport-focused invoker. But I agree, and as French say: Je pousse mémé dans les ortilles. Translation left as an exercise. well, aside from my and babelfish's inability to translate that... 1. I was planning to move the invocation reassembly and targeting into a bunch of interceptors on the server side. 2. I think your argument applies with exactly equal force to the client side interceptors and if we put the functionality for IIOP into the invoker on the server side we should for exactly the same reason eliminate client side interceptors everywhere and put them in the client side of more capable (than IIOP) invokers. Just because we haven't used the client interceptors for any customization doesn't mean they aren't a good idea. If we ever found a use for including additional context information, we would be able to include it in all transports simply be writing one client and one server interceptor and adding it to the chains for the objects we wanted it for. For IIOP, I think this would result in the fewest changes: I think basically we'd just have to add the C++ (or whatever) code to send the additional context info. thanks david Cheers, Sacha -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Jencks Sent: lundi, 24. février 2003 21:02 To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread On 2003.02.24 14:35 Bill Burke wrote: Bill, what I find really boring and unpleasant about this discussion is that I can't find any evidence that you read most of my posts, or that you Ditto. I thought I did read your stuff and replied appropriately. Maybe I missed something. What I saw you propose for non-Java and I'll quote you: outside world something corba and proxy-like ci1 ci2 some kind of invoker-like thing si1 si2 actual target object My argument against this was that you would have to maintain 2 separate interceptor chains on the server. For IIOP the chain would be (as you stated) IIOPInvoker ci1 ci2 si1 si2 actual target object. For RMI/Java the chain would be DP ci1 ci2 network --- JRMPInvoker si1 si2 I voiced a similar problem with AOP where the AOP interceptors would have to know whether the call had traveled through a remote proxy object. I wrote the lengthy description/picture below in an attempt to find out what you are talking about, since this argument doesn't make sense to me. I 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
RE: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread
Maybe we're confusing 2 issues here: 1. writing a maintainable usable jboss dtm 2. supporting corba etc. I realize I am not entirely comfortable with the client interceptors, and I notice that they are not really used in the local proxies. I don't think my idea of using the client interceptors inside a corba invoker will work, because there will be no way to simulate a client environment. So I'm basically abandoning my idea of always using the same client interceptors for all clients including local, remote, and corba. I think the current client interceptor stack configuration system may be lousy and need redesign, but that is sort of a third question. I think it should not be tied to the invoker but to local/remote/corba choice. The fact that all client interceptor stacks today are identical supports this view. How about: server side interceptor gets back the functionality of suspending transactions that are not needed (for not supoorted and requires new) client side interceptor for remote client does this also, to avoid creating unneeded branches. Local clients won't need the client side tx interceptor. The corba clients will continue creating branches based on the corba transaction policy, and we will import all such transactions that arrive via corba immediately. The server side tx interceptor may suspend these tx in the case of notsupported and requiresNew. There's nothing we can do about the remote corba tm creating unneeded branches, and the simplest way to deal with them is simply to import them so when a prepare/commit/etc request comes we just let our tm deal with it. - (in reference to Hiram's comment) On the client side, I need 2 pieces of functionality: a tx-support aware interceptor per remote object (ejb name, not instance) and an xaresource per remote jboss server. I'm still convinced this is by far the simplest possible implementation for dtm. I think writing the xaresource as a transport-level interceptor will have many many simplifying advantages, but it is not necessary, only about half as complex as my previous solution. It could be written once and plugged in some other way, but I don't see the point in using an inferior architecture to an interceptor stack. Thanks david --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] 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.
method
ejb-nameEJBNAME/ejb-name
method-nameMETHOD/method-name
method-params
method-paramPARAM-1/method-param
method-paramPARAM-2/method-param
...
method-paramPARAM-n/method-param
/method-params
/method
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: [JBoss-dev] org.jboss.aop.MethodMetaData
big snip 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] 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 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
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] 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 big snip 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
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 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
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 big snip 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 --- 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
RE: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread
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. 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
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 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 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
Re: [JBoss-dev] Automated JBoss(Branch_3_2 WonderLand) Testsuite Results: 23-February-2003
Of these errors, I think 2 are won't fix. MissingClassUnitTestCase would require a nasty backport from head that I don't want to do. Perhaps we should remove or disable the test? DeployXMBeanUnitTestCase is breaking because the xdoclet version used to build 3.2 has the wrong version of the xmbean_1_0.dtd bundled in it. Fixing this would require (or be best done) by upgrading to a more current version of xdoclet. This requires changing all our build files to remove the formerly deprecated and now disallowed xdoclet source=blah usage. I'm not thrilled about doing this either. david jencks On 2003.02.23 13:56 [EMAIL PROTECTED] wrote: JBoss daily test results SUMMARY Number of tests run: 1116 Successful tests: 1110 Errors:6 Failures: 0 [time of test: 2003-02-23.18-00 GMT] [java.version: 1.3.1_05] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.3.1_05-b02] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Windows 2000] [os.arch: x86] [os.version: 5.0] Useful resources: - http://users.jboss.org/~starksm/Branch_3_2/2003-02-23.18-00 for the junit report of this test. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS Suite: SecurityUnitTestCase Test:runValidDynDurSub(org.jboss.test.jbossmq.test.SecurityUnitTestCase) Type:error Exception: java.lang.InternalError Message: Test timeout - Suite: DeployXMBeanUnitTestCase Test:testDeployUserXMBean(org.jboss.test.jmx.test.DeployXMBeanUnitTestCase) Type:error Exception: org.jboss.deployment.DeploymentException Message: create operation failed for package file:/C:/cvs/JBoss3.2/jboss-3.2/testsuite/output/lib/user-xmbean.sar; - nested throwable: (org.jboss.deployment.DeploymentException: Error parsing the XML file: org.xml.sax.SAXParseException: Attribute persistPolicy with value Never must have a value from the list NEVER ONUPDATE NOMOREOFTENTHAN ONTIMER .; - nested throwable: (javax.management.NotCompliantMBeanException: Error parsing the XML file: org.xml.sax.SAXParseException: Attribute persistPolicy with value Never must have a value from the list NEVER ONUPDATE NOMOREOFTENTHAN ONTIMER .)) - Suite: MissingClassUnitTestCase Test: testDeployServiceWithoutClass(org.jboss.test.jmx.test.MissingClassUnitTestCase) Type:error Exception: org.jboss.deployment.DeploymentException Message: create operation failed for package file:/C:/cvs/JBoss3.2/jboss-3.2/testsuite/output/lib/missingclass-service.xml; - nested throwable: (javax.management.InstanceNotFoundException: jboss.test:name=missingclasstest is not registered.) - Suite: JSR77SpecUnitTestCase Test:testNavigation(org.jboss.test.management.test.JSR77SpecUnitTestCase) Type:error Exception: javax.management.InstanceNotFoundException Message: jboss.management.local:J2EEApplication=cts-v1cmp.ear,J2EEServer=Local,j2eeType=EJBModule,name=cts-v1cmp.jar is not registered. - Suite: HttpsUnitTestCase Test:testJSSE(org.jboss.test.security.test.HttpsUnitTestCase) Type:error Exception: java.net.BindException Message: Address in use: JVM_Bind - Suite: SRPUnitTestCase Test:testEchoArgs(org.jboss.test.security.test.SRPUnitTestCase) Type:error Exception: java.lang.reflect.UndeclaredThrowableException Message: - --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- 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
RE: [JBoss-dev] TxInterceptor split is really really bad
On 2003.02.22 00:13 Bill Burke wrote: Tx propagation can be pushed to a generic remoting framework/object if the underlying transport supports it. Class/Interface Metadata can't. Why not? I thought the txsupport stuff demonstrated that it could. It certainly doesn't depend on any special properties of TrunkInvoker: it is there only because the remoting framework was not generic when I wrote it. david Bill --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread
This is really boring and unpleasant, bill. We don't seem to 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 know about the method calls), and the clustering thingy that picks a remote server) \/ * client side end of the transport. I believe this is essentially the remoting framework. || || || * server side end of the transport. This may include some kind of relationship with a thread pool. Lets assume the work is dispatched with a thread, no matter how it is picked and how synchronous/asynchronous it is. Anyway, the reconstituted invocation object has its interceptor iterator replaced with one for the transport specific server side interceptors \/ * Several interceptors (server side interceptors specific to the transport. In my current dtm implementation, one of these would import an xid in the invocation into the server side tm) . * Target selector. Based on the metadata, this interceptor picks and locates a target object, and calls invoke(invocation) on it. This is the end of the transport specific server side interceptor chain. \/ \/ * Server side target object. This is analogous to the current server side ejb Container object. It replaces the invocation's interceptor iterator and starts it off by calling invocation.invokeNext(). \/ Server side interceptors. For non remotable objects and for no transport local remotable objects, the original interceptor chain would continue here. ... \/ Final interceptor. This uses the metadata and the method information to do something to the actual object instance we are working with. \/ || object of interest. Note that this requires, for remotable objects, being able to get two interceptor iterators: one for the client side iterators, and one for the server side iterators. For local only objects, you only need one interceptor iterator. For objects that can be local or remote, looking up the server side target object can be avoided if the client side interceptor iterator also
[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?
I've noticed that in some other parts of jboss org.jboss.util.MethodHash is
used to construct a serializable and presumably unique key for a method
that does take into account both the methods name and list of parameter
types. Unfortunately for use w/jmx, the MethodHash also encodes the class
from which the method originates. Perhaps we can generalize MethodHash to
cover the case where the class is not known.
david jencks
---
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] TxInterceptor split is really really bad
I'm getting kind of tired of what I find vague complaints without detailed explanations of the framework in which you think there might be a problem. I think remote AOP is going to need; 1. some representation of the object you are calling 2. client interceptors. For instance, to get the security context. 3. a transport mechanism 4. something on the other end of the transport mechanism to find the right target 5. server side interceptors If you disagree please explain in detail what you propose. Personally I think the AOP stuff should do this always, with a possible null transport mechanism, at least for remotable objects. If you agree, then I hope you will agree that there has to be some metadata on the client side to define the client interceptors and the transport. If there is some place to put metadata, why can't I use it for the tx support? I would like to note that my future plans for this involve method specific interceptor chains with a variety of client side and server side tx interceptors, each one performing half of the TxSupport work. No maps, just different specialized interceptors, with different interceptors per method depending on the tx support. I also think you will admit that even in aop you could have two interceptors even if both were on the server side: one to get the tx from the context if appropriate or remove it if appropriate, one to start a new tx if appropriate. On 2003.02.21 16:12 Bill Burke wrote: I've been thinking and should have posted this before. Your design is fataly flawed when I start applying it to the AOP framework. Your design assumes that there is a proxy sitting in front of everything. In AOP this is not the case. If you look at varia/src/org/jboss/aop/plugins/TxSupport.java you'll see that I had to combine the clientInvoke and serverInvoke into one method because there is no proxy object between the application code and the object instance. You could have written two separate interceptors, one with the client invoke and one with the server invoke. Ok...no problem you sayWell, think of what happens when the app developer decides to remote an AOP'd object. I will have to have 2 sets of interceptor chains and have to figure out whether the call is a remote call or local. Well, I guess I could insert a flag into the Invocation on whether the call went through a proxy or not. Do you mean transport? I don't understand. But do you see where I'm going? nope I don't think its a good design to rely on the client to handle transaction semantics. I don't think its a good idea for the server to have to rely on client logic unless it really has to. So serialization and RMI are a bad idea because they allow moving server logic to the client? In this case the transaction support HAS TO RELY ON THE CLIENT TRANSACTION MANAGER or there will be no dtm. I don't understand why you are getting your knickers in such a twist when I want to move some static data to the client to reduce complexity and comply with the industry standard dtm spec. david All and all, my gut tells me that the current client/tx design will cause problems. I want interceptor designers in general to avoid this kind of dependency. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David Jencks Sent: Wednesday, February 19, 2003 11:02 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really good On 2003.02.19 09:37 Bill Burke wrote: What you implemented is fine. My only problem with it is that I think it is more logical to let the server decide if it needs the tx, and that I think the registration callback could be avoided (with minimal redundant client side bookkeeping) even if the decision is made on the server side. I got the impression that this implementation would also be used in the other invokers, and that made me worry about CORBA interoperability. If this approach will not be used with the IIOP invoker, I have no problem with it. Yes this was my exact worry and still is. That we'll have to have a different set of interceptors on the server side for different transports. This is unexceptable because we want each EJB to be able to listen to and service calls from different transports at the same time. David, I'm not suggesting to redesign your code, but is the design flexible enough so that we could switch to a server-side based design? Iteration is a fine thing I don't think we will have problems adapting my current design to use corba. Before we continue I think we should get a clear understanding of what is supposed to happen when the corba tx policy and the j2ee tx support disagree. Does anyone know where this is described in specs? Basically the corba design says if there is a transaction in the context it must always
RE: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread
On 2003.02.21 18:58 Bill Burke wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Hiram Chirino Sent: Friday, February 21, 2003 6:44 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] TxInterceptor split is really really bad --- Bill Burke [EMAIL PROTECTED] wrote: I would like to note that my future plans for this involve method specific interceptor chains with a variety of client side and server side tx interceptors, each one performing half of the TxSupport work. No maps, just different specialized interceptors, with different interceptors per method depending on the tx support. H...thanks for mentioning this. The AOP framework will have to change to support his type of per method intercepiton. Currently the ClassAdvisor asks the InterceptorFactory for an instance of an Interceptor and adds it to the interceptor chain. For what you want to do, this will have to change. The InterceptorFactory should be responsible for adding interceptors to the chain. Otherwise, my isolation and separation of metadata, interceptors, and pointcuts will be broken. I don't think that you model would be too broken. His interceptors should only hav to implement the org.jboss.aop.InvocationFilterInterceptor interface: boolean intercepts(Invocation invocation); The org.jboss.aop.Invocation.invokeNext() will skip over interceptors that do not interested the invocation. Currently invokeNext() interogates the intercetors on every invocation, but I think that we should be able to keep a per Invocation interceptor stack cache so that we can skip the interogation after the first method call. Per method interceptor stacks will eliminate the need to the interceptor filter interface. That's not the issue. The issue is configuration. He wants to avoid sending over metadata about the method/tx bindings. WTF??? I want to send to the client the information about whether an exising tx needs to be sent, and as I have indicated I would like to encode this in which interceptor is in each method's client side invocation chain. Until we have method specific interceptor chains, I need a method to tx support map. TO do this he creates a Mandatory.java class and attaches it to the method. You see now? Actually David, you actually have almost the same memory footprint. As what??? WIthout per method , you have one instance of the Tx interceptor. WIth, you have an instance per interceptor. Almost the same as a hashmap of methodnames and strings identifying the tx attribute. yes, this is obvious. Maybe we have really different ideas about what will go in the interceptor stack for an aop object. I was assuming that it would go like this, just like an ejb: local aop object ci1 ci2 local invoker si1 si2 si2 actual aop object and remote aop object ci1 ci2 real invoker (transport) si1 si2 actual aop object where ci are client interceptors and si are server interceptors. This way any aop object gets the same interceptor stack no matter if it is local or remote. I don't really care if either the local or remote aop object is the actual object or some kind of proxy: I don't think it makes any difference. I don't see why the remote aop thingy can't be the actual object rather than a dynamic proxy, it's just that all the work gets tossed over to a different server. If you plan to leave out the ci's for local aop objects I want to know how you have any chance of getting even mildly similar behavior between local and remote versions. === corba My current (limited) understanding of corba tx support leads me to believe that any working corba implementation will use the corba tx policies to their fullest advantage and will have already established and enlisted a transaction branch on the corba tx manager whenever it sends a transaction with an invocation. We can't do anything about this, so we can't save it some work if it happens to be calling a method (not supported or requires new) that won't use the tx that was sent. I assume we can't install any kind of real client side interceptors in corba, we just have to take what is sent to us. If this is wrong please speak up. Therefore, we have to duplicate the functionality of the client side interceptors somewhere on the server side in the iiop invoker. If we don't do this we will get the wrong semantics. I don't know exactly how the iiop invoker works, but I would hope that we could set it up so that it looks like: outside world something corba and proxy-like ci1 ci2 some kind of invoker-like thing si1 si2 actual target object This is really similar to a local ejb call, except it may not start with a dynamic proxy ( I don't know what it would start with). Also I don't know it the invoker-like thing would do nothing or something.
Re: [JBoss-dev] Schedule forConnection management changes in 3.2
I fixed the immediate problem in jboss 3.2, other versions to follow shortly. The intent of this feature is to encourage you to clean up after yourself by closing all database connections you get before you leave the ejb method they were obtained in. This is contrary to the jca spec requirement that the app server allow you to hold connection handles across ejb method invocations, hooking the handle up to a suitable (tx and security) ManagedConnection for each ejb call. I cannot emphasize enough how strongly I advise you to obtain and close your connection handles in each ejb call. If you require holding connection handles over method invocations, set the CachedConnectionManager SpecCompliant attribute to true in the jboss-jca.sar/META-INF/jboss-service.xml file. I can't imagine how your code could have worked with the previous jboss code without running out of connection handles just as fast, so if there are additional problems please let me know. thanks david jencks On 2003.02.20 05:19 Jonas Partner wrote: Hi I was hoping that someone could provide guidance on whether we should continue trying to develop with 3.2 or whether to try and drop back to 3.0.x, at the moment 3.2 RC1, RC2 and a clean 3.2 build from CVS do not seem to be closing local transaction database connections see the below stack from the testsuite. This is proving critical since under moderate usage we can quickly run out of connections .Since we have a freeze date approaching in the next week or two we are looking for guidance as to when the changes in connection management are likely to be completed and also whether any assistance with this would be welcome. Regards Jonas Partner Software Developer Xerox Mobile Solutions Cambridge 2003-02-20 09:20:38,100 INFO [org.jboss.test.jca.ejb.CachedConnectionSessionBean] ejb activate never called, conn == null 2003-02-20 09:20:38,100 INFO [org.jboss.resource.connectionmanager.CachedConnectionManager] Could not find a close method on alleged connection objects. Please close your own connections. java.lang.Exception: Stack Trace at org.jboss.resource.connectionmanager.CachedConnectionManager.closeAll(CachedConnectionManager.java:357) at org.jboss.resource.connectionmanager.CachedConnectionManager.popMetaAwareObject(CachedConnectionManager.java:199) at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:190) at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:77) 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.StatelessSessionContainer.internalInvoke(StatelessSessionContainer.java:322) at org.jboss.ejb.Container.invoke(Container.java:652) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:549) at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:338) at sun.reflect.GeneratedMethodAccessor49.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261) at sun.rmi.transport.Transport$1.run(Transport.java:148) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:144) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701) at java.lang.Thread.run(Thread.java:536) !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0 Transitional//EN HTMLHEAD META http-equiv=Content-Type content=text/html; charset=iso-8859-1 META content=MSHTML 6.00.2800.1126 name=GENERATOR STYLE/STYLE /HEAD BODY bgColor=#ff DIVFONT face=Arial size=2Hi /FONT/DIV DIVFONT face=Arial size=2I was hoping that someone could provide guidance on whether we should continue trying to develop with 3.2/FONT/DIV DIVFONT face=Arial size=2or whether to try and drop back to 3.0.x,nbsp;/FONTFONT face=Arial
[JBoss-dev] JBoss 3.2 xdoclet support
I updated xdoclet to use the 3.2 cmp2 dtd if requested and tried to update the template to include the new elements, in particular optimistic locking and audit fields. I'd really appreciate some feedback on whether this actually works before I update the jb4 cvs copy of xdoclet. Remember that in jb 4 you can get and compile a copy of xdoclet by going to the xdoclet module and running ./build.sh You may need to remove old last.xdoclet.build and last.xdoclet.update files to get a proper cvs update. I still have no plans to upgrade the xdoclet used to build 3.2 Thanks david jencks --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Dependant classloader repository
On 2003.02.19 03:43 Peter Antman wrote:
On Tue, 2003-02-18 at 20:08, David Jencks wrote:
I don't yet understand what problem you are trying to solve. The
problem I
know of with the current deployment set up and LoaderRepositories is
that
the only package type you can specify a LoaderRepsository in is an
.ear.
This however is easy to fix without more kinds of LoaderRepositories.
You
can already add several .ears to the same named LoaderRespository and
(if
there are no bugs) redeploy each independently.
Could have been working but is not:
if(
di.repositoryName.equals(DeploymentInfo.DEFAULT_LOADER_REPOSITORY) ==
false )
{
log.debug(Destroying ear loader
repository:+di.repositoryName);
try
{
this.server.unregisterMBean(di.repositoryName);
}
catch(Exception e)
{
log.warn(Failed to unregister ear loader repository, e);
}
}
The first ear to get redeployed will destroy the repository! And will
make the other ear:s *very* confused.
OK, but thats a bug in the implementation. Where is this code?
My experience is also that a component that gets its classloader swaped
under the hood without beeing properly redeployed will behave very
eratic. Thats why.
You can't do that with standard mbeans, the classs--mbean dependency is
tracked and used to undeploy/redeploy the mbean instance as the classloader
is cycled. Maybe we can extend this to modelmbeans and ejbs.
thanks
david
//Peter
I don't know if all
dependencies between .ears are properly taken care of.
What will having a deeper hierarchy of LoaderRepositories get you? I
don't
understand the situation in which this would be useful.
Also, I am planning on moving the dependency computatations out of
ServiceController and into an mbean interceptor (with some global
supporting objects).
thanks
david jencks
On 2003.02.18 13:51 Peter Antman wrote:
Hi,
I would like to share some ideas about extensions to the current
classloader to see if I am totally on the wrong track and if it
perhaps would be a welcome addition to JBoss.
First I have to say that I still find the new classloader
architecture somewhat limiting. If you have the following two
conditions:
1. You do not want components/classes globally available in the
repository because this stops from implementation/interface
versioning.
2. You want to be able to partition your stuff in several deployable
components (locally/remote), but which uses each other (EJB:s
calling EJB:s, MBeans calling MBeans (locally and through RMI),
MBeans calling EJB:s and EJB:s calling MBeans).
The you basically have to do a couple of things:
1. Be very paranoid about what classes get stuffed into your
components.
2. Up to the last classloader change stuff almost every class at the
global
level anyhow, through lib or a dynamic classloader deployer, and
after
the latest changes at least place all interfaces statically
available in the global classloader repository.
To me this hinders one of the aspects that has always was dear to
me: hot redeploy.
Here is an idea (with a working test implementation) to make these
obstacles possible to overcome:
Create a repository which may delegate to other repositories (not
just
a parent repository) and make this configurable in jboss-app.xml
Create dependency checks so that lifecykling a component with a
repository which have dependent repositories will make also these
components lifecyking.
Here is the basic steps I took to create this:
1. Create a DelegatingLoaderRepository which extends
HeirarchicalLoaderRepository3. The delegating repository takes a
list of repositories to delegate to if the normal loading fails.
2. Factor out repository handling in EARDeployer, extends EARDeployer
with a DependantEARDeployer.
EAR:s deployed through this new deployer may set up dependencies
between its own repository and the repositories of other
components. These other repositories must however also have been
created through the dependent deployer; because the repository
must
be installed in the ServiceController.
For a repository created through the DependantEARDeployer a
RepositoryProxy is created which will work as a proxy to track
dependency events from the ServiceController. The proxy also takes
the DeploymentInfo of the components; which makes it possible for
the proxy to redeploy its component!
server.createMBean( org.jboss.deployment.RepositoryProxy,
proxy);
serviceController.create(proxy,depends);
serviceController.start(proxy);
server.setAttribute( proxy, new
Attribute
RE: [JBoss-dev] TxInterceptor split is really really good
On 2003.02.19 09:37 Bill Burke wrote: What you implemented is fine. My only problem with it is that I think it is more logical to let the server decide if it needs the tx, and that I think the registration callback could be avoided (with minimal redundant client side bookkeeping) even if the decision is made on the server side. I got the impression that this implementation would also be used in the other invokers, and that made me worry about CORBA interoperability. If this approach will not be used with the IIOP invoker, I have no problem with it. Yes this was my exact worry and still is. That we'll have to have a different set of interceptors on the server side for different transports. This is unexceptable because we want each EJB to be able to listen to and service calls from different transports at the same time. David, I'm not suggesting to redesign your code, but is the design flexible enough so that we could switch to a server-side based design? Iteration is a fine thing I don't think we will have problems adapting my current design to use corba. Before we continue I think we should get a clear understanding of what is supposed to happen when the corba tx policy and the j2ee tx support disagree. Does anyone know where this is described in specs? Basically the corba design says if there is a transaction in the context it must always be transmitted and imported on the server whereas j2ee does not always need to import the tx. The purpose of the client side interceptor is to not generate tx branches that won't be used. I think that any reasonable corba implementation is going to follow corba semantics and always generate a transaction branch on the client for the remote call, since as far as the corba spec goes, if the call is made within a tx the transaction will in fact be used on the server. In my view the heaviest part of the process is generating a tx branch on the client: once it is generated, then it has to be prepared and/or committed. The communication overhead on these messages is likely to dwarf any other resource usage. The choices I can see here are: 1. only generate the branch if it is needed, but do it right away. This is what I implemented and I think it is simplest and the only one that is likely to be comprehensible when someone looks at it in a week or two. 2. Only generate the branch if it is needed but do it after the work is done. I think this is Ole's proposal. This introduces a lot of bookkeeping on the client to associate client side transactions to branches. I don't think I'd be able to maintain this code, in a week I wouldn't remember how it worked. After spending a day to figure it out, I'd simplify it to (1). 3. Always generate a branch immediately, but have the xaresource return read-only on prepare if the tx did not need to be imported. This is unacceptable because it forces 2pc in the case that there is only one other branch. Don't we need a client side method-to-method-attributes map anyway for many other purposes such as determining if a return value can be cached? david Bill --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. 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 --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss Remoting Commit
Woo hoo!! Thanks! This looks great!!! Will you guys mind if I fix minor oversights I notice (such as making handler names consistently upper case in ServerInvoker)? Partly so I don't forget and partly to think out loud as I read the code, here are my initial comments: 1. There's kind of an impedance mismatch between the remoting invoke method and all the interceptor invoke methods. The interceptors all have some kind of invocation object that includes method name, args, sig, and extra params: these are separate arguments in the remoting's invoke method. I think the same signature everywhere would make integration everywhere easier. In particular, I'd like the Invoker to implement whatever Interceptor interface we finally come up with. I'm mildly in favor of a single Invocation argument, even though it is not the most natural for the original jmx remoting use case. 2. I need to have essentially client and server side invoker interceptors (e.g. the InvokerXAResource). I'm sure others will think of uses for this when it is available. If we decide one way or another on (1) I can implement this possibly using an adapter that could be removed if we decide to go with a single Invocation argument. 3. So far I've just looked at the socket server invoker. I want to be able to plug in a thread pool (implementing a standard interface). I also want the stuff that's done in the thread to be set up as an interceptor chain. For instance, I want the extract the xid from the invocation and import it or prepare/commit/rollback/recover/forget to be in one or more interceptors. I think most of this is taken care of by the selection of ServerInvocationHandler: I can make these be my interceptors. I wonder if a clearer architecture would move the ServerInvoker invoke(byte[]) method into a separate class that the transport mechanism runnable classes subclass. This object would then be the standardized object submitted to something like the jca 1.5 work interface. [this is the jca 1.5 thread pool, and it provides for both synchronous and asynchronous execution of a Work object. I like the idea of always using the same kind of object, but the Work interface itself is not appropriate since the contents of the ExecutionContext (tx context or xid) would not be determined until the thread starts processing. I'd like to build the jca 1.5 implementation out of more basic units.] 4. I haven't found yet how the client invokers get set up in the client. Are there situations in which they are obtained through rmi? Should they be mbeans in a client-side jmx server? Should this be optional? Working on the TrunkInvoker I made the client side piece into several mbeans that got created/registered when the first one got deserialized as a remote object. This considerably simplified keeping track of the pieces. Is something like this a good idea here too or at least compatible with what you have? 5. Since I think it is possible that jmx could be used without aop and aop without jmx, I'd like to suggest that we make a new module invocation that has the interceptor interface, and the Invocation and InvocationResponse objects in it. Otherwise I don't see how to unify our view of these fundamental classes without intruducing artificial dependencies. I'd like to get to work on the interceptor stuff I mentioned, so I'd like to get comments on this soon so at least I'll know how much I'll have to fight:- This is awesome work. Thanks again david jencks On 2003.02.19 00:54 Jeff Haynie wrote: I commited the jboss-remoting code tonight. There is now a separate module named jboss-remoting, and it is aliased in jboss-mx and jboss-head (because mx needs it). It looks like all 3 modules are compiling fine. There is more work that Tom and I are doing this week to try and wrap up the initial testing - however, the code should compile fine and the code isn't yet referenced at all anywhere in the server so shouldn't cause any problems. If it does cause problems in the next day or so, please let me or Tom Elrod ([EMAIL PROTECTED]) if you have any issues - or just fix them and let me and him know. -Jeff http://www.freeroller.net/page/jhaynie !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0 Transitional//EN HTMLHEAD META HTTP-EQUIV=Content-Type CONTENT=text/html; charset=us-ascii TITLEMessage/TITLE META content=MSHTML 6.00.2800.1141 name=GENERATOR/HEAD BODY DIVFONT face=Arial size=2SPAN class=323323305-19022003I commited the jboss-remoting code tonight.nbsp; There is now a separate module named jboss-remoting, and it is aliased in jboss-mx and jboss-head (because mx needs it)./SPAN/FONT/DIV DIVFONT face=Arial size=2/FONTnbsp;/DIV DIVSPAN class=323323305-19022003FONT face=Arial size=2It looks like all 3 modules are compiling fine.nbsp; There is more work that Tom and I are doing this week to try and wrap up the initial testing - however, the code should compile fine
Re: [JBoss-dev] TxInterceptor split is really really good
I'm now quite confused about what you are arguing for. 1. There is currently no support whatsoever in any jboss version for transactions over CORBA/IIOP, nor has there ever been. I have not yet considered how best to implement this. I don't think this will be used very much so I am willing to provide a special implementation for this if it will not fit into the jta framework well. 2. I can't tell from the specs I have read so far what the relationship between the CORBA tx policy and the j2ee tx policy is supposed to be. 3. JTA performs the registration of the branch at the same time as the xid is generated through the tx.enlist(XAResource) and xares.start(xid) calls. There is no other way to get an xid. 4. Your final arguments look to me as if they are supporting exactly what I implemented. Are you aware that the current implementation works only with the trunk invoker? Are you aware that the InvokerXAResource is a client-side mbean? thanks david On 2003.02.18 09:52 Ole Husgaard wrote: David Jencks wrote: On 2003.02.17 04:20 Ole Husgaard wrote: Deciding to avoid the resource registration callback when the tx is not used at server side is a fine thing. However, I fail to see why this decision has to be done at the client side. All the information needed for the decision is already available at the server side. Of course the information about whether an xid needs to be generated and a branch registered is available on the server side. My idea is to move this information to the client side, where the xid generation and branch registration actually happen. If deciding if the tx is needed in the server is done on the server side - as I suggest - an xid will still be generated and transmitted from the server side. But these are relatively cheap operations. The really expensive operation is the callback done to the client for registering the server TM as a resource to the client TM, because of network latency. IMO this results in an easier to understand system with more appropriate division of responsibilities. I think that letting the server decide if the server needs the tx is more logical. However, letting the client decide can also be implemented in a understandable and maintainable way, as only a few specialized interceptors are involved. For CORBA, I think we should to things the CORBA way: Always propagate the tx (if one is available at client side), and let the server side TM (or interceptors) decide if a resource registration callback is needed. I agree this is necessary for CORBA, but I do not think it is appropriate for JTA based clients, such as other jboss instances. For simplicity and ability to interoperate with the clustering code, which chooses which server to communicate with in the invoker, I have made all java clients into JTA based clients. For JRMP, we define our own protocol, so here we can do whatever we like. My concern is about the IIOP transport: This should not have any special hacks that could break interoperability with non-java code. Most CORBA implementations always do the registration callback, as the import of the tx is done in the transport code. But by using a custom CORBA tx interceptor at the server side, we can simply store the xid in a threadlocal, and delay the tx import until we know if it is needed. From reading the 1.2 CORBA OTS spec my understanding is that CORBA does not support the transaction attributes (such as requiresNew and NotSupported) that would result in transferring a tx identifier but not importing it. CORBA has OTSPolicy, but that doesn't map directly to the EJB transactional attributes. For example, there is no equivalent of requiresNew. However, OTSPolicy could be used to sometimes avoid generating a new branch at the client, and transferring it to the server. Unfortunately, I don't think that JacORB supports OTSPolicy. Therefore if the CORBA client is JTA, I strongly suspect it will generate an xid for the branch from the transaction (if it exists) and send it along. This is exactly the behavior I am trying to avoid, since we have to support these types of tx support. Still, these operations are relatively cheap. The expensive operation is the callback to the client to enlist the server as a resource in the client TM. So, why not use this sequence of events: 1) client starts tx 2) client calls ejb proxy 3) (NO client side tx interceptor. Always attaches tx to invocation.) umm, this was the original client side tx interceptor. Yes.. 4) invocation is routed to correct transport mechanism (such as by the HA Invoker interceptor)(AFAIK not yet written as an interceptor) 5) Invocation is received at server side. 6) The server decides if the resource registration callback is needed. The last step is where I see the possibility for avoiding the expensive
Re: [JBoss-dev] Dependant classloader repository
I don't yet understand what problem you are trying to solve. The problem I know of with the current deployment set up and LoaderRepositories is that the only package type you can specify a LoaderRepsository in is an .ear. This however is easy to fix without more kinds of LoaderRepositories. You can already add several .ears to the same named LoaderRespository and (if there are no bugs) redeploy each independently. I don't know if all dependencies between .ears are properly taken care of. What will having a deeper hierarchy of LoaderRepositories get you? I don't understand the situation in which this would be useful. Also, I am planning on moving the dependency computatations out of ServiceController and into an mbean interceptor (with some global supporting objects). thanks david jencks On 2003.02.18 13:51 Peter Antman wrote: Hi, I would like to share some ideas about extensions to the current classloader to see if I am totally on the wrong track and if it perhaps would be a welcome addition to JBoss. First I have to say that I still find the new classloader architecture somewhat limiting. If you have the following two conditions: 1. You do not want components/classes globally available in the repository because this stops from implementation/interface versioning. 2. You want to be able to partition your stuff in several deployable components (locally/remote), but which uses each other (EJB:s calling EJB:s, MBeans calling MBeans (locally and through RMI), MBeans calling EJB:s and EJB:s calling MBeans). The you basically have to do a couple of things: 1. Be very paranoid about what classes get stuffed into your components. 2. Up to the last classloader change stuff almost every class at the global level anyhow, through lib or a dynamic classloader deployer, and after the latest changes at least place all interfaces statically available in the global classloader repository. To me this hinders one of the aspects that has always was dear to me: hot redeploy. Here is an idea (with a working test implementation) to make these obstacles possible to overcome: Create a repository which may delegate to other repositories (not just a parent repository) and make this configurable in jboss-app.xml Create dependency checks so that lifecykling a component with a repository which have dependent repositories will make also these components lifecyking. Here is the basic steps I took to create this: 1. Create a DelegatingLoaderRepository which extends HeirarchicalLoaderRepository3. The delegating repository takes a list of repositories to delegate to if the normal loading fails. 2. Factor out repository handling in EARDeployer, extends EARDeployer with a DependantEARDeployer. EAR:s deployed through this new deployer may set up dependencies between its own repository and the repositories of other components. These other repositories must however also have been created through the dependent deployer; because the repository must be installed in the ServiceController. For a repository created through the DependantEARDeployer a RepositoryProxy is created which will work as a proxy to track dependency events from the ServiceController. The proxy also takes the DeploymentInfo of the components; which makes it possible for the proxy to redeploy its component! server.createMBean( org.jboss.deployment.RepositoryProxy, proxy); serviceController.create(proxy,depends); serviceController.start(proxy); server.setAttribute( proxy, new Attribute(DeploymentInfo,di)); The repository is then added to ServiceController in the start face of the deployment (so that all its subcomponents is available and added to the repository). So, how can this be used? Say we have component A and B. B needs to call A. jboss-app of A: jboss-app loader-repository:loader=compA/loader-repository jboss-app of B: jboss-app loader-repository loaderRepositoryClass=org.jboss.mx.loading.DelegatingLoaderRepository objectName=:loader=compB dependsdepends:loader=compA/depends/loader-repository When both components are deployed it is possible to: - redeploy B as ordinary - redeploy A with new classes - B will be redeployed automatically Extended example: component C is dependent of B: jboss-app loader-repository loaderRepositoryClass=org.jboss.mx.loading.DelegatingLoaderRepository objectName=:loader=compC dependsdepends:loader=compB/depends/loader-repository - Redeploying B will lead to C being redeployed: - Redeploying A will leas to B and C being redeployed. Circular example: B depends on A, C depends on B and A: loader-repository loaderRepositoryClass=org.jboss.mx.loading.DelegatingLoaderRepository objectName=:loader=compC dependsdepends:loader=compA
Re: [JBoss-dev] jbosscx rfe 677512
I'd rather figure out what is causing the problem. Does cursor == open statement? Open resultset? Are you using cmp? If bmp are you closing everything in finally blocks? A known problem is that the jca-jdbc wrappers don't track open statements for you and close them when you close the connection handle. This is not hard to fix, but I haven't done it yet. You might be able to make a solution to this problem in any cvs version of jboss if you can come up with some sql that will fail if too many cursors are open on a connection. All cvs versions now have CheckValidConnectionSQL for you to set: if you set it, this statement is executed when a connection is taken out of the pool and before it is handed out to your application. If you can determine from some Oracle info which connection it is and how many cursors or how many times the statement has been called, you could throw some kind of exception that would force the connection to be destroyed. thanks david jencks On 2003.02.17 11:50 Sonnek, Ryan wrote: i posted this request about a week ago, and would like to know any developers thoughts on this. to summerize, i'd like to be able to force a datasource to timeout any connections in the pool after a period of time. we're running jboss 3.0.6 with oracle 8i and right now and we're constantly running into an error Maximum number of cursors exceeded. being able to timeout connections that have been used heavily to restore those cursors is the only idea i had to get around this error. unfortunately this is a MAJOR problem for us right now, since we can't get our application up with 24/7 reliability. it only takes a matter of minutes of heavy activity to exceed 300 cursors on oracle. if there is some other way to get around this error, i would appreciate any feedback. or, if this is a planned enhancement, when would it be integrated? thanks in advance. Ryan --- 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] Problem with the 3.0 branch testsuite
On 2003.02.16 05:17 Scott M Stark wrote: I'm running it now. Thanks. You know that adding a file to cvs does not commit it right? You need to do a cvs add and then a commit to incorporate new files into cvs. yes. I don't know what was going on. After I committed the pathological test files my missing adds showed up when I did cvs update (with A status). Maybe adrian added them but didn't commit david Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, February 15, 2003 6:28 PM Subject: Re: [JBoss-dev] Problem with the 3.0 branch testsuite I've checked in what I think Adrian intended and the rest of my patch, I think, if cvs is acting right. When I ran the testsuite locally before these checkins there was only ONE error, from the wont-fix mbean missing class testcase. Scott, can you run the 3.0 tests to make sure everything got checked in? thanks david jencks --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] (no subject)
there appear to be problems with the InvocationResponse and cmp2 in jb4. Quite a few (e.g. cmp2 commerce) tests are failing apparently due to an InvocationResponse object being supplied as a pk value: 2003-02-16 11:55:52,592 DEBUG [org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreEntityCommand.OrderEJB] Executing SQL: UPDATE ORDER_DATA SET SHIPPING_ADDRESS=? WHERE ORDER_NUMBER=? 2003-02-16 11:55:52,593 ERROR [org.jboss.ejb.plugins.LogInterceptor] EJBException, causedBy: java.sql.SQLException: Wrong data type: For input string: org.jboss.invocation.InvocationResponse@90f9c3 at org.hsqldb.Trace.getError(Unknown Source) at org.hsqldb.Trace.error(Unknown Source) at org.hsqldb.Column.convertObject(Unknown Source) at org.hsqldb.jdbcPreparedStatement.setObject(Unknown Source) at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.setObject(WrappedPreparedStatement.java:607) at org.jboss.ejb.plugins.cmp.jdbc.JDBCUtil.setParameter(JDBCUtil.java:278) at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.setArgumentParameters(JDBCAbstractCMPFieldBridge.java:301) at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.setPrimaryKeyParameters(JDBCAbstractCMPFieldBridge.java:289) at org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCEntityBridge.setPrimaryKeyParameters(JDBCEntityBridge.java:581) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreEntityCommand.execute(JDBCStoreEntityCommand.java:117) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.storeEntity(JDBCStoreManager.java:614) at org.jboss.ejb.entity.CMPInterceptor.storeEntity(CMPInterceptor.java:218) Perhaps someone who knows how this area works better than I could fix this. thanks david jencks --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] TxInterceptor split is really really good
On 2003.02.15 09:57 Igor Fedorenko wrote: David Jencks wrote: The design goal is to produce a working dtm that does not make unnecesary inter-vm calls. The functionality of the client side tx interceptor appears to be unavailable with the CORBA OTS if we do not write some client side stuff. Here is the sequence of events for a call between vms where a transaction is started on the client (could be a standalone app or a JBoss instance) client starts tx client calls ejb proxy client side tx interceptor attaches tx to invocation ONLY if tx support for the method is supports, mandatory, or requires. In all other cases it makes sure no tx is attached to the invocation. invocation is routed to correct transport mechanism (such as by the HA Invoker interceptor)(AFAIK not yet written as an interceptor) Now that we have the target jboss instance determined, the InvokerXAResource enlists with the tx if present, thus getting an xid to transport. If no tx is present, it doesnt enlist with null. The xid is sent over the transport mechanism with the marshalled invocation. The server-side half of the transport mechanism/invoker extracts the xid if present, puts in in an ExcecutionContext, and uses the WorkManager associated with the invoker to execute the call to the ejb. The WorkManager communicates with the server-side tx manager to start and end the transaction at the beginning and end of the call. The method returns. At some later time, the tx commits. Since the InvokerXAResource was enlisted in the tx IF AND ONLY IF the tx was actually sent to do work on the server jboss instance, it will get a commit call only if the server jboss instance actually did work in the tx. If it did work in the tx, it gets (possible) prepare and commit calls with the xid for its branch, and makes a invocation to call an XATerminatorContainer, which has the same method call syntax as an ejb container. In any case it handles communicating the prepare and commit calls to the server-side tx manager. I am a little bit confused here. What do you mean by client starts tx? For example, if the client is a standalone app, will this app actually create instance of TransactionImpl and be responsible for executing two phase commit protocol? Yes. I wouldn't recommend doing a multi-participant tx from a standalone client, but if you want to risk it you can. You'll have hard time recovering from failures of such clients. Even if you provided full-blown transaction manager with tx logs and proper recovery algorithm on the client side, the client can simply quit after executing phase one of 2PC and never come back. Have I missed something? My first implementation was with a limited client tx manager that would only handle one branch. After some encouragement from other developers I changed to always using the same tx manager and tx implementation everywhere. By default a standalone client is set up without tx logging. Having only one tx/txmanager implementation results in less code and equivalent behavior if the client is sensible and only uses 1pc. The 2pc stuff is mostly intended for server instance to server instance calls, but if you want to stick your neck out from a standalone client I don't see why I should try to stop you. Does this seem reasonable? thanks david -- Igor Fedorenko Think smart. Think automated. Think Dynamics. www.thinkdynamics.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Problem with the 3.0 branch testsuite
Adrian added this, I figured out how to fix it and will commit shortly. CVS is acting very strangely, and I ran into a similar problem. I added a file (cvs add) but it is not showing up when I do cvs update. I suspect the same thing happened to Adrian. david jencks On 2003.02.15 19:38 Scott M Stark wrote: It looks like some new tests are not completely checked in as the following errors are due to missing org.jboss.test.entity.interfaces. If you added this test check that the added files have been committed. compile-classes-only: [mkdir] Created dir: /usr/local/jboss/JBoss3.0/jboss-all/testsuite/output/classes [javac] Compiling 854 source files to /usr/local/jboss/JBoss3.0/jboss-all/testsuite/output/classes [javac] /usr/local/jboss/JBoss3.0/jboss-all/testsuite/src/main/org/jboss/test/entity/test/PathologicalUnitTestCase.java:13: cannot resolve symbol [javac] symbol : class EntitySession [javac] location: package interfaces [javac] import org.jboss.test.entity.interfaces.EntitySession; [javac] ^ [javac] /usr/local/jboss/JBoss3.0/jboss-all/testsuite/src/main/org/jboss/test/entity/test/PathologicalUnitTestCase.java:14: cannot resolve symbol [javac] symbol : class EntitySessionHome [javac] location: package interfaces [javac] import org.jboss.test.entity.interfaces.EntitySessionHome; Scott Stark Chief Technology Officer JBoss Group, LLC --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- 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] Problem with the 3.0 branch testsuite
I've checked in what I think Adrian intended and the rest of my patch, I think, if cvs is acting right. When I ran the testsuite locally before these checkins there was only ONE error, from the wont-fix mbean missing class testcase. Scott, can you run the 3.0 tests to make sure everything got checked in? thanks david jencks On 2003.02.15 19:38 Scott M Stark wrote: It looks like some new tests are not completely checked in as the following errors are due to missing org.jboss.test.entity.interfaces. If you added this test check that the added files have been committed. compile-classes-only: [mkdir] Created dir: /usr/local/jboss/JBoss3.0/jboss-all/testsuite/output/classes [javac] Compiling 854 source files to /usr/local/jboss/JBoss3.0/jboss-all/testsuite/output/classes [javac] /usr/local/jboss/JBoss3.0/jboss-all/testsuite/src/main/org/jboss/test/entity/test/PathologicalUnitTestCase.java:13: cannot resolve symbol [javac] symbol : class EntitySession [javac] location: package interfaces [javac] import org.jboss.test.entity.interfaces.EntitySession; [javac] ^ [javac] /usr/local/jboss/JBoss3.0/jboss-all/testsuite/src/main/org/jboss/test/entity/test/PathologicalUnitTestCase.java:14: cannot resolve symbol [javac] symbol : class EntitySessionHome [javac] location: package interfaces [javac] import org.jboss.test.entity.interfaces.EntitySessionHome; Scott Stark Chief Technology Officer JBoss Group, LLC --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- 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] is head all messed up?
Thanks, I think this is fixed. Learning dom4j and xpath is taking a little
while...
david jencks
On 2003.02.14 16:01 Scott Rehorn wrote:
Looks like jboss-local-jdbc.rar:
2003-02-14 11:31:35,640 ERROR
[org.jboss.deployment.scanner.URLDeploymentScanner] Failed to deploy:
org.jboss.deployment.scanner.URLDeploymentScanner$DeployedURL@da28e63d{
url=file:/D:/cvs2/jboss-head/build/output/jboss-4.0.0alpha/server/all/deploy
/jboss-local-jdbc.rar, deployedLastModified=0 }
org.jboss.deployment.DeploymentException: exception in init of
file:/D:/cvs2/jboss-head/build/output/jboss-4.0.0alpha/server/all/deploy/jbo
ss-local-jdbc.rar; - nested throwable:
(org.jboss.deployment.DeploymentException: Could not read dd; - nested
throwable: (org.dom4j.DocumentException: Server returned HTTP response
code:
403 for URL: http://java.sun.com/dtd/connector_1_0.dtd Nested exception:
Server returned HTTP response code: 403 for URL:
http://java.sun.com/dtd/connector_1_0.dtd))
I don't find a jboss-jca directory under connector-- maybe it's a name
change side effect? Many more things fail after this following the same
pattern.
-Original Message-
From: David Jencks [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 14, 2003 11:57 AM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] is head all messed up?
Odd, this should be supplied from an entity resolver (see
connector/src/resources/jboss-jca/META-INF/jboss-service.xml).
What was
getting deployed at the time?
david jencks
On 2003.02.14 14:37 Scott Rehorn wrote:
Another data point:
I am seeing numerous errors on startup too, even with run
-c default.
This
is with a jdk1.3 build from a new head checkout on Win2k Pro this
morning.
Looks like the error is that 403s are causing dtd
validations to fail. I
am
behind a corp firewall, so I was attributing the problem to
that (since
head
compiled and built fine just last week for example). I also
tried setting
the various -Dproxy parameters, but that didn't seem to help.
- scott r
Quest Software, Inc.
example:
org.jboss.deployment.DeploymentException: Could not read
dd; - nested
throwable: (org.dom4j.DocumentException: Server returned
HTTP response
code:
403 for URL: http://java.sun.com/dtd/connector_1_0.dtd
Nested exception:
Server returned HTTP response code: 403 for URL:
http://java.sun.com/dtd/connector_1_0.dtd)at
org.jboss.deployment.XSLSubDeployer.findDd(XSLSubDeployer.java:443)
at
org.jboss.deployment.XSLSubDeployer.init(XSLSubDeployer.java:304)
at
org.jboss.deployment.MainDeployer.init(MainDeployer.java:630)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:562)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:538)
at
java.lang.reflect.Method.invoke(Native Method)
...
-Original Message-
From: Bill Burke [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 13, 2003 12:35 PM
To: Jboss-Dev
Subject: [JBoss-dev] is head all messed up?
Is anybody seeing a million errors just booting run -c all?
How bad is the
testsuite failing? I'm in the process of getting a clean
checkout, but
would appreciate if anybody has any info right now.
Thanks,
Bill
---
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to
get a FREE
Thawte SSL guide and find the answers to all your SSL
security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 3.2//EN
HTML
HEAD
META HTTP-EQUIV=Content-Type CONTENT=text/html;
charset=iso-8859-1
META NAME=Generator CONTENT=MS Exchange Server version
5.5.2654.45
TITLERE: [JBoss-dev] is head all messed up?/TITLE
/HEAD
BODY
PFONT SIZE=2Another data point: /FONT
/P
PFONT SIZE=2I am seeing numerous errors on startup too,
even with run
-c default. This is with a jdk1.3 build from a new head
checkout on Win2k
Pro this morning. /FONT/P
PFONT SIZE=2Looks like the error is that 403s are causing dtd
validations to fail. I am behind a corp firewall, so I was
attributing
the problem to that (since head compiled and built fine
just last week
for example). I also tried setting the various -Dproxy
parameters, but
that didn't seem to help. /FONT/P
PFONT SIZE=2- scott r/FONT
BRFONT SIZE=2Quest Software, Inc./FONT
/P
BR
PFONT SIZE=2example: /FONT
/P
PFONT SIZE
RE: [JBoss-dev] The new tests target
The testsuite is just not scalable, Bill, and is inappropriate for module level unit tests. Having the compile take 5-10 minutes for running just one test is ludicrous. If you want to object, object to the change note when I announced this facility. I will see about getting all the module tests to run with the main testsuite and included in the report. ricardo, all my tests just used stuff from build/tests or build/gen/tests (or whatever its named). I think we need an additional src/test-resource directory in each module for this purpose. We need a definition in buildfragments/defaults.ent and to include it in the _default:tests target. david jencks On 2003.02.14 11:26 Bill Burke wrote: Please put these tests in the testsuite. We need nightly reports on the stability of JBoss. Plus, if they aren't integrated with testsuite you risk somebody breaking your code with a new change to the core. Again, put these tests in testuiste Thanks, Bill Burke Chief Architect JBoss Group, LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Ricardo Argüello Sent: Friday, February 14, 2003 9:58 AM To: [EMAIL PROTECTED] Subject: [JBoss-dev] The new tests target Hi, I'm trying to use the new tests target for JBoss-Media (CVS module: jboss-media). I need to access files with media to do some unit testing. I'm doing it this way: From jboss-head/media/src/test/org/jboss/media/JBossMediaUnitTestCase.java: ... ClassLoader classLoader = Thread.currentThread().getContextClassLoader(); InputStream inputStream = classLoader.getResourceAsStream(resourceName); ... Most of the code was copied from the jboss-head/testsuite/src/main/org/jboss/test/cmp2/lob testcase. In that testcase, getResourceAsStream works with files under src/resources resourceName is in my case data/image.png. I've tried putting the file in src/main, src/resources and src/test with no luck: I can't read the file. I can run the test from Eclipse, running JBossMediaUnitTestCase as a Junit test, build tests gives me Errors: testcase name=testMediaBeanProperties time=0.016 error type=java.lang.NullPointerExceptionjava.lang.NullPointerExcepti on at org.jboss.media.JBossMediaUnitTestCase.createFileFromResource(JBos sMediaUnitTestCase.java:196) at org.jboss.media.JBossMediaUnitTestCase.setUp(JBossMediaUnitTestCas e.java:61)/error /testcase testcase name=testMediaFormatRegistry time=0.0 error type=java.lang.NullPointerExceptionjava.lang.NullPointerExcepti on at org.jboss.media.JBossMediaUnitTestCase.createFileFromResource(JBos sMediaUnitTestCase.java:196) at org.jboss.media.JBossMediaUnitTestCase.setUp(JBossMediaUnitTestCas e.java:61)/error /testcase testcase name=testHeaderExtraction time=0.0 error type=java.lang.NullPointerExceptionjava.lang.NullPointerExcepti on at org.jboss.media.JBossMediaUnitTestCase.createFileFromResource(JBos sMediaUnitTestCase.java:196) at org.jboss.media.JBossMediaUnitTestCase.setUp(JBossMediaUnitTestCas e.java:61)/error *Maybe* some change needs to be added to tools/etc/buildfragments/targets.ent? Where should I put files to be readed with ClassLoader.getResourceAsStream(...) form within a JUnit testcase to be run with the new tests target? You can find all the code in the jboss-media CVS module. Thanks in advance, Ricardo Argüello [EMAIL PROTECTED] www.freeroller.net/page/ricardo -- I took the red pill. --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing
Re: [JBoss-dev] The new tests target
I can set up so that running /build/build.sh tests runs all module build suites and the main testsuite and put all results in the testsuite/output/reports. This should be pretty easy, I can do it this weekend. I really think that encouraging people to write actual unit tests by making it really easy will greatly help the quality of our code. Right now we have almost no unit tests, only integration tests. Please distinguish between unit tests and integration tests. david jencks On 2003.02.14 13:14 Scott M Stark wrote: Its true that the main problem is xdoclet here. Its also the reason for a bug report about excessive memory usage during compilation. We need to have a comprehensive testsuite for the reason that Bill states, we cannot rely on a developer having to run individual module tests to validate system wide changes. We also do need to address the monolithic nature of the testsuite. Having to run xdoclet and the compile to rerun a test is a waste of time. This does need to be broken down without losing the ability to run comprehensive testsuites. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Bill Burke [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, February 14, 2003 9:23 AM Subject: RE: [JBoss-dev] The new tests target -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Jencks Sent: Friday, February 14, 2003 12:03 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] The new tests target The testsuite is just not scalable, Bill, and is inappropriate for module level unit tests. Having the compile take 5-10 minutes for running just one test is ludicrous. If its not scalable, fix it. We need tests to run with the nightly build, this is more important than saving you 5-10 minutes. When I make a global change like InvocationResponse, I need to know that all tests are being executed so that I don't fuck up everything. I turn off recompilation in testsuite/build.xml when I need to run a test more than once quickly. Why does the stupid buildsystem rerun XDoclet everytime you do a build? Why isn't there any dependency checking? This is the real problem and why the build takes so fucking long. I miss the days of the 2.x series when the buildsystem wasn't such a burden... If you want to object, object to the change note when I announced this facility. I will see about getting all the module tests to run with the main testsuite and included in the report. This should have been done in the first place before it was encouraged to put in modules tests ricardo, all my tests just used stuff from build/tests or build/gen/tests (or whatever its named). I think we need an additional src/test-resource directory in each module for this purpose. We need a definition in buildfragments/defaults.ent and to include it in the _default:tests target. david jencks --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] is head all messed up?
Odd, this should be supplied from an entity resolver (see connector/src/resources/jboss-jca/META-INF/jboss-service.xml). What was getting deployed at the time? david jencks On 2003.02.14 14:37 Scott Rehorn wrote: Another data point: I am seeing numerous errors on startup too, even with run -c default. This is with a jdk1.3 build from a new head checkout on Win2k Pro this morning. Looks like the error is that 403s are causing dtd validations to fail. I am behind a corp firewall, so I was attributing the problem to that (since head compiled and built fine just last week for example). I also tried setting the various -Dproxy parameters, but that didn't seem to help. - scott r Quest Software, Inc. example: org.jboss.deployment.DeploymentException: Could not read dd; - nested throwable: (org.dom4j.DocumentException: Server returned HTTP response code: 403 for URL: http://java.sun.com/dtd/connector_1_0.dtd Nested exception: Server returned HTTP response code: 403 for URL: http://java.sun.com/dtd/connector_1_0.dtd)at org.jboss.deployment.XSLSubDeployer.findDd(XSLSubDeployer.java:443) at org.jboss.deployment.XSLSubDeployer.init(XSLSubDeployer.java:304) at org.jboss.deployment.MainDeployer.init(MainDeployer.java:630) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:562) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:538) at java.lang.reflect.Method.invoke(Native Method) ... -Original Message- From: Bill Burke [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 13, 2003 12:35 PM To: Jboss-Dev Subject: [JBoss-dev] is head all messed up? Is anybody seeing a million errors just booting run -c all? How bad is the testsuite failing? I'm in the process of getting a clean checkout, but would appreciate if anybody has any info right now. Thanks, Bill --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 3.2//EN HTML HEAD META HTTP-EQUIV=Content-Type CONTENT=text/html; charset=iso-8859-1 META NAME=Generator CONTENT=MS Exchange Server version 5.5.2654.45 TITLERE: [JBoss-dev] is head all messed up?/TITLE /HEAD BODY PFONT SIZE=2Another data point: /FONT /P PFONT SIZE=2I am seeing numerous errors on startup too, even with run -c default. This is with a jdk1.3 build from a new head checkout on Win2k Pro this morning. /FONT/P PFONT SIZE=2Looks like the error is that 403s are causing dtd validations to fail. I am behind a corp firewall, so I was attributing the problem to that (since head compiled and built fine just last week for example). I also tried setting the various -Dproxy parameters, but that didn't seem to help. /FONT/P PFONT SIZE=2- scott r/FONT BRFONT SIZE=2Quest Software, Inc./FONT /P BR PFONT SIZE=2example: /FONT /P PFONT SIZE=2org.jboss.deployment.DeploymentException: Could not read dd; - nested throwable: (org.dom4j.DocumentException: Server returned HTTP response code: 403 for URL: A HREF=http://java.sun.com/dtd/connector_1_0.dtd; TARGET=_blankhttp://java.sun.com/dtd/connector_1_0.dtd/A Nested exception: Server returned HTTP response code: 403 for URL: A HREF=http://java.sun.com/dtd/connector_1_0.dtd; TARGET=_blankhttp://java.sun.com/dtd/connector_1_0.dtd/A) nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; at org.jboss.deployment.XSLSubDeployer.findDd(XSLSubDeployer.java:443)nbsp; at org.jboss.deployment.XSLSubDeployer.init(XSLSubDeployer.java:304) nbsp;nbsp; at org.jboss.deployment.MainDeployer.init(MainDeployer.java:630) nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:562) nbsp;nbsp;nbsp;nbsp; at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:538) nbsp;nbsp;nbsp;nbsp; at java.lang.reflect.Method.invoke(Native Method)/FONT/P PFONT SIZE=2.../FONT /P PFONT SIZE=2gt; -Original Message-/FONT BRFONT SIZE=2gt; From: Bill Burke [A HREF=mailto:[EMAIL PROTECTED];mailto:[EMAIL PROTECTED]/A]/FONT BRFONT SIZE=2gt; Sent: Thursday, February 13, 2003 12:35 PM/FONT BRFONT SIZE=2gt; To: Jboss-Dev/FONT BRFONT SIZE=2gt; Subject: [JBoss-dev] is head all messed up?/FONT BRFONT SIZE=2gt; /FONT BRFONT SIZE=2gt; /FONT BRFONT SIZE=2gt; Is anybody seeing a million errors just booting run -c all?nbsp; /FONT BRFONT SIZE=2gt; How bad is the/FONT BRFONT SIZE=2gt; testsuite failing?nbsp; I'm in the process of getting a clean /FONT BRFONT SIZE=2gt; checkout, but/FONT BRFONT
RE: [JBoss-dev] is head all messed up?
thanks, I meant jca-sar/META-INF/jboss-service.xml
It was working for me yesterday but I haven't updated since Bill's checkin.
Don't see why that would affect this. This code has been there for at
least several weeks...
david jencks
On 2003.02.14 16:01 Scott Rehorn wrote:
Looks like jboss-local-jdbc.rar:
2003-02-14 11:31:35,640 ERROR
[org.jboss.deployment.scanner.URLDeploymentScanner] Failed to deploy:
org.jboss.deployment.scanner.URLDeploymentScanner$DeployedURL@da28e63d{
url=file:/D:/cvs2/jboss-head/build/output/jboss-4.0.0alpha/server/all/deploy
/jboss-local-jdbc.rar, deployedLastModified=0 }
org.jboss.deployment.DeploymentException: exception in init of
file:/D:/cvs2/jboss-head/build/output/jboss-4.0.0alpha/server/all/deploy/jbo
ss-local-jdbc.rar; - nested throwable:
(org.jboss.deployment.DeploymentException: Could not read dd; - nested
throwable: (org.dom4j.DocumentException: Server returned HTTP response
code:
403 for URL: http://java.sun.com/dtd/connector_1_0.dtd Nested exception:
Server returned HTTP response code: 403 for URL:
http://java.sun.com/dtd/connector_1_0.dtd))
I don't find a jboss-jca directory under connector-- maybe it's a name
change side effect? Many more things fail after this following the same
pattern.
-Original Message-
From: David Jencks [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 14, 2003 11:57 AM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] is head all messed up?
Odd, this should be supplied from an entity resolver (see
connector/src/resources/jboss-jca/META-INF/jboss-service.xml).
What was
getting deployed at the time?
david jencks
On 2003.02.14 14:37 Scott Rehorn wrote:
Another data point:
I am seeing numerous errors on startup too, even with run
-c default.
This
is with a jdk1.3 build from a new head checkout on Win2k Pro this
morning.
Looks like the error is that 403s are causing dtd
validations to fail. I
am
behind a corp firewall, so I was attributing the problem to
that (since
head
compiled and built fine just last week for example). I also
tried setting
the various -Dproxy parameters, but that didn't seem to help.
- scott r
Quest Software, Inc.
example:
org.jboss.deployment.DeploymentException: Could not read
dd; - nested
throwable: (org.dom4j.DocumentException: Server returned
HTTP response
code:
403 for URL: http://java.sun.com/dtd/connector_1_0.dtd
Nested exception:
Server returned HTTP response code: 403 for URL:
http://java.sun.com/dtd/connector_1_0.dtd)at
org.jboss.deployment.XSLSubDeployer.findDd(XSLSubDeployer.java:443)
at
org.jboss.deployment.XSLSubDeployer.init(XSLSubDeployer.java:304)
at
org.jboss.deployment.MainDeployer.init(MainDeployer.java:630)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:562)
at
org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:538)
at
java.lang.reflect.Method.invoke(Native Method)
...
-Original Message-
From: Bill Burke [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 13, 2003 12:35 PM
To: Jboss-Dev
Subject: [JBoss-dev] is head all messed up?
Is anybody seeing a million errors just booting run -c all?
How bad is the
testsuite failing? I'm in the process of getting a clean
checkout, but
would appreciate if anybody has any info right now.
Thanks,
Bill
---
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to
get a FREE
Thawte SSL guide and find the answers to all your SSL
security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 3.2//EN
HTML
HEAD
META HTTP-EQUIV=Content-Type CONTENT=text/html;
charset=iso-8859-1
META NAME=Generator CONTENT=MS Exchange Server version
5.5.2654.45
TITLERE: [JBoss-dev] is head all messed up?/TITLE
/HEAD
BODY
PFONT SIZE=2Another data point: /FONT
/P
PFONT SIZE=2I am seeing numerous errors on startup too,
even with run
-c default. This is with a jdk1.3 build from a new head
checkout on Win2k
Pro this morning. /FONT/P
PFONT SIZE=2Looks like the error is that 403s are causing dtd
validations to fail. I am behind a corp firewall, so I was
attributing
the problem to that (since head compiled and built fine
just last week
for example). I also tried setting the various -Dproxy
parameters, but
that didn't seem to help. /FONT/P
PFONT SIZE=2- scott r/FONT
BRFONT
RE: [JBoss-dev] TxInterceptor split is really really good
On 2003.02.13 08:22 Bill Burke wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Jencks Sent: Wednesday, February 12, 2003 11:42 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] TxInterceptor split is really really good The design goal is to produce a working dtm that does not make unnecesary inter-vm calls. The functionality of the client side tx interceptor appears to be unavailable with the CORBA OTS if we do not write some client side stuff. Here is the sequence of events for a call between vms where a transaction is started on the client (could be a standalone app or a JBoss instance) client starts tx client calls ejb proxy client side tx interceptor attaches tx to invocation ONLY if tx support for the method is supports, mandatory, or requires. In all other cases it makes sure no tx is attached to the invocation. invocation is routed to correct transport mechanism (such as by the HA Invoker interceptor)(AFAIK not yet written as an interceptor) Ok, its now time to split this HA stuff outI'll work on that nowOf course, unfortunately, this split requires an InvocationResponse object. Why is this unfortunate? I thought it was a great idea that is long overdue. I don't see the point in doing it 2 or three times, so I'd do it after all the interceptors are based on a common interface/model. Now that we have the target jboss instance determined, the InvokerXAResource enlists with the tx if present, thus getting an xid to transport. If no tx is present, it doesnt enlist with null. The xid is sent over the transport mechanism with the marshalled invocation. The server-side half of the transport mechanism/invoker extracts the xid if present, puts in in an ExcecutionContext, and uses the WorkManager associated with the invoker to execute the call to the ejb. The WorkManager communicates with the server-side tx manager to start and end the transaction at the beginning and end of the call. This is all TrunkInvoker stuff, correct? Now why the reliance on TrunkInvoker? Couldn't you just create a new Invocation object and pass it down the interceptor chain? I guess this would break in the current implementation of clustering though as you say above Since I don't like having to reimplement the same code over and over and over again without any new ideas, I'm waiting for Jeff's remote jmx refactoring to use for all the transport mechanisms. I happened to implement the trunk invoker version before I knew about the remote jmx stuff. Consider it as a possibly unfinished example. For instance, the Work instance supplied to the WorkManager is in dire need of refactoring. I'm also not entirely sure I want to use the exact Work interfaces, in particular ExecutionContext. The method returns. At some later time, the tx commits. Since the InvokerXAResource was enlisted in the tx IF AND ONLY IF the tx was actually sent to do work on the server jboss instance, it will get a commit call only if the server jboss instance actually did work in the tx. If it did work in the tx, it gets (possible) prepare and commit calls with the xid for its branch, and makes a invocation to call an XATerminatorContainer, which has the same method call syntax as an ejb container. In any case it handles communicating the prepare and commit calls to the server-side tx manager. -- Of course, with optimized in-vm calls, you don't have an InvokerXAResource and don't generate an xid for the method call. -- Now lets consider the alternative. Without knowing the tx support of every method in the ejb, EVERY transaction MUST be ALWAYS enlisted with the InvokerXAResource, have an xid generated for it, get transmitted over the transport mechansim, and enrolled in the server-side transaction manager. Then when commit comes, totally useless prepare and commit calls must be made to a remote vm for a transaction that COULD NOT POSSIBLY HAVE DONE ANY WORK. We have one remote call to do the requested work and up to two calls to no purpose. Ok, back to the InvocationResponse thingy we were discussing offline What is this InvokerXAResource? Is it on the client/initiating TM of a distTrans that represents the remote TM? yes Why does an XID have to be generated before the call to the remote TM? There's probably some way to avoid this, but it is the xa way and I think it is the simplest thing that will work. This stuff is already so complicated and understood by so few people I think following the standard model is highly advisable. Is it required that the client TM generate the Xid that the server must use? Only if you want anyone else ever at any time to be able to understand the system. If you want to write it, prove that it works, and be the sole
RE: [JBoss-dev] TxInterceptor split is really really good
On 2003.02.13 10:35 Bill Burke wrote: The design goal is to produce a working dtm that does not make unnecesary inter-vm calls. The functionality of the client side tx interceptor appears to be unavailable with the CORBA OTS if we do not write some client side stuff. Here is the sequence of events for a call between vms where a transaction is started on the client (could be a standalone app or a JBoss instance) client starts tx client calls ejb proxy client side tx interceptor attaches tx to invocation ONLY if tx support for the method is supports, mandatory, or requires. In all other cases it makes sure no tx is attached to the invocation. invocation is routed to correct transport mechanism (such as by the HA Invoker interceptor)(AFAIK not yet written as an interceptor) Ok, its now time to split this HA stuff outI'll work on that nowOf course, unfortunately, this split requires an InvocationResponse object. Why is this unfortunate? I thought it was a great idea that is long overdue. I don't see the point in doing it 2 or three times, so I'd do it after all the interceptors are based on a common interface/model. Yes, its long overdue. I'm doing it nowBy unfortunate I meant, this is a pain in the ass to do since it affects a lot of code and a lot of code must be retested. I DO see a point in doing it 2 or 3 times. Its easier to debug if problems come up. Since I know the current invocation architecture works for the most part I first port the InvocationResponse there. When that works, I know I have a good foundation to do the new interceptor(AOP) and invokers changes. Well that's the way I like to do things I like small testable refactorings also:-). I just don't see the point in adapting this stuff to one set of interfaces, then next week adapting the same code to another set of interfaces. I have one more or less working example (trunk invoker) and think I will make fewer mistakes porting if I only do it once to the future jmx transport stuff. BTW I strongly encourage you to use the module level testing framework I put in to do real unit tests on these components rather than the typical integration type tests we usually write. I found it a really big help working on the dom4j refactoring. Now that we have the target jboss instance determined, the InvokerXAResource enlists with the tx if present, thus getting an xid to transport. If no tx is present, it doesnt enlist with null. The xid is sent over the transport mechanism with the marshalled invocation. The server-side half of the transport mechanism/invoker extracts the xid if present, puts in in an ExcecutionContext, and uses the WorkManager associated with the invoker to execute the call to the ejb. The WorkManager communicates with the server-side tx manager to start and end the transaction at the beginning and end of the call. This is all TrunkInvoker stuff, correct? Now why the reliance on TrunkInvoker? Couldn't you just create a new Invocation object and pass it down the interceptor chain? I guess this would break in the current implementation of clustering though as you say above Since I don't like having to reimplement the same code over and over and over again without any new ideas, I'm waiting for Jeff's remote jmx refactoring to use for all the transport mechanisms. I happened to implement the trunk invoker version before I knew about the remote jmx stuff. Consider it as a possibly unfinished example. For instance, the Work instance supplied to the WorkManager is in dire need of refactoring. I'm also not entirely sure I want to use the exact Work interfaces, in particular ExecutionContext. I don't think you should be using any of the TrunkInvoker or WorkManager specifics to do TM communication. If you have some sort of TxInterceptor that handles all this Xid stuff, then there's no reason you can't create a temporary new Invocation object that will be passed along the same interceptor chain and invoked on the remote TM, or be able to extract the information you need to do remote TM communication from the current Invocation object. Even without Jeff's refactor, shouldn't you be able to do this? That's what I try to do right now. In particular, prepare/commit etc calls use the same transport mechanism and target-finding approach as ejb calls: they go to a XATerminatorContainer which looks like an ejb container but talks to the TM. The client side stuff (InvokerXAResource) is already completely generic (I think). The server side stuff is still quite mixed up in the trunk invoker specifics. If Jeffs jmx stuff doesn't arrive soon I will probably refactor that to make it more reasonable. The method returns. At some later time, the tx
Re: [JBoss-dev] Why are we using this bogus construct
I think you are wrong, although I have trouble understanding all the issues
with this. I think this is a double checked locking idiom and I think it
is just as broken.
The guy who calls someOtherMethod will definitely see the correct hashmap,
but there is no guarantee that its state will match any particular state in
which it was put unless access to it is also synchronized.
Double checked locking is broken.
See Effective Java pp 193 ff and the various Double Checked Locking is
Broken websites.
As I understand it, problems with this construct are unlikely to appear
unless you are using something like a multiprocessor alpha box.
I think we should prove in some way that this construct is safe or remove
it.
david jencks
On 2003.02.13 13:00 Larry Sanderson wrote:
If the map is seldom modified, then you can get around synchronization
with techniques like this. It is taking advantage of the fact that
assignement is an atomic operation. If the methods are like this:
public void someMethod()
{
HashMap localMap = null;
synchronized (clients)
{
localMap = new HashMap(clients);
}
// ... read/write work on local map ...
clients = localMap;
}
public void someOtherMethod()
{
HashMap localMap = clients;
// ... read-only work on local map ...
}
Now everyone can call someOtherMethod() without invoking the cost of
synchronization, and once they obtain localMap it is guaranteed not to
be modified. But someMethod() exists for those rare times when the map
does need to be modified.
I don't think this is as useful as it once was - synchronization is much
faster than it used to be.
-Larry
Scott M Stark wrote:
I have seen this usage construct in a few places in the code and it
makes
no sense to me:
class X
{
HashMap clients = new HashMap();
public void someMethod()
{
synchronized(clients)
{
HashMap m = new HashMap(clients);
m.put(dc, cq);
clients=m;
}
...
}
public void someOtherMethod()
{
Iterator i = clients.keySet().iterator();
while( i.hasNext() )
{
...
}
}
}
The unsynchronized clients HashMap is synchronized and copied when
modified and accessed without synchronization in other contexts. This
is
not thread safe for the accesses and makes for very expensive updates.
Why isn't the HashMap simply synchronized and used without copying?
Scott Stark
Chief Technology Officer
JBoss Group, LLC
---
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Why are we using this bogus construct
This one looks to me as if it is not subject to double-checked locking type
problems. I think it is fine, since the copy is made in a synchronized
block and accessed in the same thread.
david jencks
On 2003.02.13 12:35 Dain Sundstrom wrote:
This seems backwards to me. I usually do something like this:
class X
{
HashMap clients = new HashMap();
public void someMethod()
{
synchronized(clients)
{
m.put(dc, cq);
}
...
}
public void someOtherMethod()
{
HashMap clientsCopy = null;
synchronized(clients)
{
clientsCopy = new HashMap(clients);
}
Iterator i = clientsCopy.keySet().iterator();
while( i.hasNext() )
{
...
}
}
}
For the insert, you only get a quick synchronized around the add, and
on iteration you get a single copy in the synchronize. If the
iteration very small and quick, I sometimes put the entire iteration in
the synchronized block, but you need to be careful about open calls.
-dain
On Thursday, February 13, 2003, at 11:20 AM, Scott M Stark wrote:
I have seen this usage construct in a few places in the code and it
makes
no sense to me:
class X
{
HashMap clients = new HashMap();
public void someMethod()
{
synchronized(clients)
{
HashMap m = new HashMap(clients);
m.put(dc, cq);
clients=m;
}
...
}
public void someOtherMethod()
{
Iterator i = clients.keySet().iterator();
while( i.hasNext() )
{
...
}
}
}
The unsynchronized clients HashMap is synchronized and copied when
modified and accessed without synchronization in other contexts. This
is
not thread safe for the accesses and makes for very expensive updates.
Why isn't the HashMap simply synchronized and used without copying?
Scott Stark
Chief Technology Officer
JBoss Group, LLC
---
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Why are we using this bogus construct
On 2003.02.13 13:40 Larry Sanderson wrote:
Isn't double checked locking something like this:
private HashMap cache = new HashMap();
public MyObject get(String cacheLookup) {
MyObject foo = (MyObject)cache.get(cacheLooku);
if (foo == null) {
synchronized (cache) {
foo = cache.get(cacheLooku);
if (foo == null) {
foo = new MyObject();
cache.put(cacheLookup, foo);
}
}
}
return foo;
}
I read an article in JavaWorld a long time ago that said this is not
required to work in a legitimate JVM, even though it does on all known
implementations. Unfortunately, I don't remember the how's or why's of
it.
However, this is not what the code below is all about.
Your example is way too complicated. You don't need a hashmap.
The normal example is:
private static Foo foo = null;
public static Foo getFoo() {
if (foo == null) {
synchronized (Foo.class) {
if (foo == null)
foo = new Foo();
}
}
return foo;
}
anyone calling getFoo without synchronization may observe the returned foo
in a partially initialized state.
I think the jboss code has the same problem as double checked locking --
described by Joshua Bloch as wildly counterintuitive.
But in the absence of synchronization, reading a published object
reference does not guarantee that a thread will see all of the data that
were stored in memory prior to the publication of the object reference. In
particular, reading a published object reference does not guarantee that
the reading thread will see the most recent values of the data that
constitute the internals of the referenced object.
In fact, you can
remove the synchronized block below and everything is still perfectly
thread safe. The whole point is that the member variable clients is
*NEVER* modified - only assigned to. In fact, it would drive the point
home even more if you did this:
private Map clients = Collections.EMPTY_MAP;
public void someMethod()
{
HashMap localMap = null;
localMap = new HashMap(clients);
// ... read/write work on local map ...
clients = Collections.unmodifiableMap(localMap);
}
Unless Collections.unmodifiableMap is sychronized internally, the results
from this are garbage.
public void someOtherMethod()
{
HashMap localMap = clients;
// ... read-only work on local map ...
}
I don't think localMap has a accurate view of clients unless this is
synchronized. Just as with double-checked locking, it can read a partially
initialized version of clients.
david
Here, clients is always immutable, even though someMethod is able to
update it with a new value. No synchronization, yet perfectly thread
safe (although very expensive to modify).
-Larry
David Jencks wrote:
I think you are wrong, although I have trouble understanding all the
issues
with this. I think this is a double checked locking idiom and I
think it
is just as broken.
The guy who calls someOtherMethod will definitely see the correct
hashmap,
but there is no guarantee that its state will match any particular
state in
which it was put unless access to it is also synchronized.
Double checked locking is broken.
See Effective Java pp 193 ff and the various Double Checked Locking is
Broken websites.
As I understand it, problems with this construct are unlikely to appear
unless you are using something like a multiprocessor alpha box.
I think we should prove in some way that this construct is safe or
remove
it.
david jencks
On 2003.02.13 13:00 Larry Sanderson wrote:
If the map is seldom modified, then you can get around synchronization
with techniques like this. It is taking advantage of the fact that
assignement is an atomic operation. If the methods are like this:
public void someMethod()
{
HashMap localMap = null;
synchronized (clients)
{
localMap = new HashMap(clients);
}
// ... read/write work on local map ...
clients = localMap;
}
Unless setting clients is synchronized, anyone reading clients will recieve
a view of localMap in an inderminate state.
public void someOtherMethod()
{
HashMap localMap = clients;
// ... read-only work on local map ...
}
If clients is not read in a synchronized block, it is not guaranteed to be
the same as ANY version that was set. It could be a half-written copy.
Now everyone can call someOtherMethod() without invoking the cost of
synchronization, and once they obtain localMap it is guaranteed not to
be modified. But someMethod() exists for those rare times when the map
does need to be modified.
I don't think this is as useful as it once was - synchronization is
much
faster than it used to be.
-Larry
Scott M Stark wrote:
I have seen this usage construct in a few places in the code and it
makes
no sense
Re: [JBoss-dev] Why are we using this bogus construct
On 2003.02.13 14:42 Larry Sanderson wrote:
... do a bunch of reading on double checked locking ...
OK - I think I see where you are coming from now. Wow - I have to agree
with Joshua Bloch: wildly counterintuitive. Have you ever experienced
these things failing in the way you describe?
Not personally. I think they are unlikely to fail on single processor
machines but much more likely to fail on multiprocessor alpha boxes which I
believe have a very aggresive approach to cache synchronization with main
memory. I have no direct experience with any multiprocessor machines of
any kind.
How much performance gain
do VM's really acheive by being allowed this much leniency in their
memory management?
I have no idea, but it appears to be pretty fundamental to the meaning of
synchronize.
Last question: does the typical JBoss developer know about this?
Based on todays discussion, apparently not.
david jencks
Thanks for the info,
-Larry
David Jencks wrote:
On 2003.02.13 13:40 Larry Sanderson wrote:
Isn't double checked locking something like this:
private HashMap cache = new HashMap();
public MyObject get(String cacheLookup) {
MyObject foo = (MyObject)cache.get(cacheLooku);
if (foo == null) {
synchronized (cache) {
foo = cache.get(cacheLooku);
if (foo == null) {
foo = new MyObject();
cache.put(cacheLookup, foo);
}
}
}
return foo;
}
I read an article in JavaWorld a long time ago that said this is not
required to work in a legitimate JVM, even though it does on all known
implementations. Unfortunately, I don't remember the how's or why's of
it.
However, this is not what the code below is all about.
Your example is way too complicated. You don't need a hashmap.
The normal example is:
private static Foo foo = null;
public static Foo getFoo() {
if (foo == null) {
synchronized (Foo.class) {
if (foo == null)
foo = new Foo();
}
}
return foo;
}
anyone calling getFoo without synchronization may observe the returned
foo
in a partially initialized state.
I think the jboss code has the same problem as double checked locking
--
described by Joshua Bloch as wildly counterintuitive.
But in the absence of synchronization, reading a published object
reference does not guarantee that a thread will see all of the data
that
were stored in memory prior to the publication of the object reference.
In
particular, reading a published object reference does not guarantee
that
the reading thread will see the most recent values of the data that
constitute the internals of the referenced object.
In fact, you can
remove the synchronized block below and everything is still perfectly
thread safe. The whole point is that the member variable clients is
*NEVER* modified - only assigned to. In fact, it would drive the point
home even more if you did this:
private Map clients = Collections.EMPTY_MAP;
public void someMethod()
{
HashMap localMap = null;
localMap = new HashMap(clients);
// ... read/write work on local map ...
clients = Collections.unmodifiableMap(localMap);
}
Unless Collections.unmodifiableMap is sychronized internally, the
results
from this are garbage.
public void someOtherMethod()
{
HashMap localMap = clients;
// ... read-only work on local map ...
}
I don't think localMap has a accurate view of clients unless this is
synchronized. Just as with double-checked locking, it can read a
partially
initialized version of clients.
david
Here, clients is always immutable, even though someMethod is able to
update it with a new value. No synchronization, yet perfectly thread
safe (although very expensive to modify).
-Larry
David Jencks wrote:
I think you are wrong, although I have trouble understanding all the
issues
with this. I think this is a double checked locking idiom and I
think it
is just as broken.
The guy who calls someOtherMethod will definitely see the correct
hashmap,
but there is no guarantee that its state will match any particular
state in
which it was put unless access to it is also synchronized.
Double checked locking is broken.
See Effective Java pp 193 ff and the various Double Checked Locking is
Broken websites.
As I understand it, problems with this construct are unlikely to
appear
unless you are using something like a multiprocessor alpha box.
I think we should prove in some way that this construct is safe or
remove
it.
david jencks
On 2003.02.13 13:00 Larry Sanderson wrote:
If the map is seldom modified, then you can get around
synchronization
with techniques like this. It is taking advantage of the fact that
assignement is an atomic
Re: [JBoss-dev] Why are we using this bogus construct
Do I get to update the CachedConnectionManager with the code from jb4 first? :-)) david On 2003.02.13 15:40 Stefan Reich wrote: Just as a reminder: the uncontended case for a synchronized statement is VERY fast: about 13 PowerPC instructions. I would argue safety first, use Java synchronization where possible, or advanced data structures from the concurrent package if not. If a piece of code turns out to be a scalability problem we can apply more brain power to find a better solution. In the end, the scalability problem will be somewhere unexpected anyway. BTW, I am taking bets on the most contended calling sequence with ECPerf on Jboss 3.2 with CMP before I send out the stack trace... Stefan --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jboss 2.4 to 3.x migration error
Basically, no. 2.4 behavior is wrong, 3.x behavior is according to jca spec. In either case you should be able to do: Connection con = ds.getConnection(); con.setAutocommit(false); //do work con.commit(); I don't know if it would work in 2.4 but you could also use UserTransaction in 3.x david jencks On 2003.02.13 18:07 Sonnek, Ryan wrote: migrating a small jsp app that uses an oracle database from jboss 2.4.6 to 3.0.6, the following error is recieved from a page that calls commit() after an insert/update/delete. You cannot commit with autocommit set! in 2.4, the commit was required to get any of our pages to work, and now they fail with this error. is there some way to configure a datasource in 3.x to have autocommit set to false, or in 2.4 to set it to true? thanks ahead of time. Ryan --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] TxInterceptor split is bad
In this case the client side method to tx support map uses MethodHash values as keys since the Methods themselves are not serializable. Seems to me that we should put the MethodHash values in the invocation to start with. david On 2003.02.12 17:57 Scott M Stark wrote: Another problem I see is that the TxMethod map is required on the client side as well. Makes proxies even more heavy and what do you do about a hot deploy? The hot deploy is a general issue with proxies. Whether or not this works depends on the transport endpoint. RMI/JRMP proxies do not work across a hot deploy, and most p2p transports do not. Making the proxies more robust across hot deploys using our own transports, etc. is something we should work towards. A java.lang.reflect.Method map is a very anti-hot-deploy construct because of the strong typing of the Method to its class. We should certainly look to limit the exposure of such a mapping outside of the VM. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Bill Burke [EMAIL PROTECTED] To: David Jencks [EMAIL PROTECTED]; Jboss-Dev [EMAIL PROTECTED] Sent: Wednesday, February 12, 2003 1:31 PM Subject: [JBoss-dev] TxInterceptor split is bad What if you don't have java on the client side? What if you're CORBA with OTS? You're making it harder for Non-JBoss/Java clients to integrated with us. I think this split should be undone. BTW, why the split besides code readability? Is the DTM dependent on this at all? Is the TM even accessed on the client side? --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] TxInterceptor split is really really good
The design goal is to produce a working dtm that does not make unnecesary inter-vm calls. The functionality of the client side tx interceptor appears to be unavailable with the CORBA OTS if we do not write some client side stuff. Here is the sequence of events for a call between vms where a transaction is started on the client (could be a standalone app or a JBoss instance) client starts tx client calls ejb proxy client side tx interceptor attaches tx to invocation ONLY if tx support for the method is supports, mandatory, or requires. In all other cases it makes sure no tx is attached to the invocation. invocation is routed to correct transport mechanism (such as by the HA Invoker interceptor)(AFAIK not yet written as an interceptor) Now that we have the target jboss instance determined, the InvokerXAResource enlists with the tx if present, thus getting an xid to transport. If no tx is present, it doesnt enlist with null. The xid is sent over the transport mechanism with the marshalled invocation. The server-side half of the transport mechanism/invoker extracts the xid if present, puts in in an ExcecutionContext, and uses the WorkManager associated with the invoker to execute the call to the ejb. The WorkManager communicates with the server-side tx manager to start and end the transaction at the beginning and end of the call. The method returns. At some later time, the tx commits. Since the InvokerXAResource was enlisted in the tx IF AND ONLY IF the tx was actually sent to do work on the server jboss instance, it will get a commit call only if the server jboss instance actually did work in the tx. If it did work in the tx, it gets (possible) prepare and commit calls with the xid for its branch, and makes a invocation to call an XATerminatorContainer, which has the same method call syntax as an ejb container. In any case it handles communicating the prepare and commit calls to the server-side tx manager. -- Of course, with optimized in-vm calls, you don't have an InvokerXAResource and don't generate an xid for the method call. -- Now lets consider the alternative. Without knowing the tx support of every method in the ejb, EVERY transaction MUST be ALWAYS enlisted with the InvokerXAResource, have an xid generated for it, get transmitted over the transport mechansim, and enrolled in the server-side transaction manager. Then when commit comes, totally useless prepare and commit calls must be made to a remote vm for a transaction that COULD NOT POSSIBLY HAVE DONE ANY WORK. We have one remote call to do the requested work and up to two calls to no purpose. It may seem unlikely that a small client would start a user transaction and then call an ejb method that didn't use it, but it seems considerably less implausible to me that a jboss server would call, within a transaction, a remote ejb with a non-transactional method. Looking at the OTS 1.2 spec, I notice that they do not use xids to identify branches. The tx support model appears to only support the equivalent of never, supports, and mandatory. Therefore, if a tx is present in an invocation, either an exception will be thrown or it will be used. Although no xid can be supplied by the OTS, jboss will still be responsible for calling coordinator.register_resource(jboss-resource) back in the corba client. I have no idea how the remote part of corba works, but it would obviously be advantageous to have something analogous to the InvokerXAResource in the client making this call rather than requiring a call back from jboss. david jencks On 2003.02.12 16:31 Bill Burke wrote: What if you don't have java on the client side? What if you're CORBA with OTS? You're making it harder for Non-JBoss/Java clients to integrated with us. I think this split should be undone. BTW, why the split besides code readability? Is the DTM dependent on this at all? Is the TM even accessed on the client side? Another problem I see is that the TxMethod map is required on the client side as well. Makes proxies even more heavy and what do you do about a hot deploy? Seems to me this is a bad idea. Bill --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] OracleLoginModule
snip Well, I'm working on modification of the source. There some hack (I already tryied them and they work) to check the password and go on, but I'm trying to understand I could do something better implementing on JBoss the modified DES algorithm used by Oracle to make password check in a cleaner form. Just a doubt, if I use getConnection() not only in LoginModule, but also on my applications I log to Oracle with just one user, so in this manner I will have J2ee role in use, but I couldn't use the Oracle Roles on package/stored procedure and table. Is it correct? Or Could I use getConnection(user,pwd) in my Beans? I'm not sure I understand exactly what you are trying to do, so let's see if I can explain how it works. Basically there are 2 scenarios, Application managed security and Container managed security: Application. You call ds.getConnection(user, pw). Do NOT supply a JAAS LoginModule for the datasource deployment. Use ByApplication for the pooling criteria. Your application will have to keep track of who it is running as and request connections as that user. Container. You call ds.getConnection(). DO supply a JAAS LoginModule for the datasource deployment. This has to be a LoginModule that knows it is working with a ManagedConnectionFactory. We have examples for CallerIdentity and ConfiguredIdentity. These login modules supply a Subject with a PasswordCredential that includes a reference to the ManagedConnectionFactory created as part of the datasource deployment. Such a login module can use any algorithm it likes to determine the identity and credentials of the database user. In the examples, Configured Identity always supplies the same user/pw, and CallerIdentity uses the user/pw your application is running under. It's also possible to lookup the application user in some kind of map to determine the db user/pw, although no one has contributed such a login module yet. Use ByContainer for the pooling criteria unless you have figured out how to reauthenticate the Oracle connections (some people have been working on this recently) With the Container managed security, you may wish to get the security mapping information from the database. This will mean the LoginModule will need one or more special connections to the db to query for this information. You may want to get one such connection directly from DriverManager to avoid recursion -- the login module trying to get a connection for itself needing the login module to get a connection Alternatively you could get the connection from a separately configured datasource that does not need db info to determine the security. One other point. You can specify a default user/pw in the datasource configuration file. This provides essentially the same effect as using the ConfiguredIdentity login module, but it is much simpler. The main difference is which file the password is stored in. I hope this clarifies things a bit:-) I often find all the parts to keep track of confusing. thanks david jencks Thanks for the interest and your good code JBoss src is fun!! --- all work and no play makes Jack a dull boy --- bye Stefano [EMAIL PROTECTED] www.javalinux.it MSN messanger: [EMAIL PROTECTED] ICQ uin: 122192578 Jabber: canezen #jedit IRC channel as maeste --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] OracleLoginModule
I'm very interested in this login module. Can you supply it as a "patch" in the sourceforge tracker? Otherwise I may lose track of it before I can review and commit it. Offhand it seems to me that the LoginModule should only work if the criteria was ByContainer. Are you calling ds.getConnection() or ds.getConnection(user, pw)? Can you check the code in XAManagedConnectionFactory.matchManagedConnection and BaseWrapperManagedConnectionFactory.getConnectionProperties to see if it is obvious why the match is failing? You might need to modify the OracleXAManagedConnectionFactory to provide more suitable matching behavior. (I'm looking at jboss head for these classes). thanks david jencks Hi guys, I wrote a login module specific for Oracle DataBase, that try to authenticate a user on Oracle DataSource and map Oracle Role on J2ee Role. I think it could be very interesting for guys that have jboss and Oracle together, because you could manage roles and user just in one enviroment. I tried it on my enviroment and seems to work only if I set in Oracle-xa-service.xml attribute name="Criteria">ByApplication/attribute> If I set it to ByContainer I get this error: 15:14:02,562 WARN [JBossManagedConnectionPool] Destroying connection that could not be successfully matched: org.jboss.resource.adapter.jdbc.xa.oracle.XAOracleManagedConnection@462631 And connection still Opened on the DB. Could you please explain me what's happen. Thank you in advance BTW I attached my source, what about it? Couldn't it be useful for anyone? image.tiff> OracleServerLoginModule.java>
Re: [JBoss-dev] OracleLoginModule
On Monday, February 3, 2003, at 12:01 PM, Stefano Maestri wrote: Il lun, 2003-02-03 alle 16:03, David Jencks ha scritto: I'm very interested in this login module. Can you supply it as a "patch" in the sourceforge tracker? Otherwise I may lose track of it before I can review and commit it. I'd glad to do it when it will work in ByContainer Mode Offhand it seems to me that the LoginModule should only work if the criteria was ByContainer. As I said it works only in ByApplication criteria Are you calling ds.getConnection() or ds.getConnection(user, pw)? the last one. If you call ds.getConnection(user, pw) you MUST NOT provide a LoginModule and you must use the ByApplication criteria if your adapter does not support reauthentication or ByNothing if it does. Login modules are for use only with Container manager security, which basically means you always call ds.getConnection(). thanks david jencks Can you check the code in XAManagedConnectionFactory.matchManagedConnection and BaseWrapperManagedConnectionFactory.getConnectionProperties to see if it is obvious why the match is failing? You might need to modify the OracleXAManagedConnectionFactory to provide more suitable matching behavior. (I'm looking at jboss head for these classes). I'm taking a look. Thanks for the interest. thanks david jencks excerpt>Hi guys, I wrote a login module specific for Oracle DataBase, that try to authenticate a user on Oracle DataSource and map Oracle Role on J2ee Role. I think it could be very interesting for guys that have jboss and Oracle together, because you could manage roles and user just in one enviroment. I tried it on my enviroment and seems to work only if I set in Oracle-xa-service.xml attribute name="Criteria">ByApplication/attribute> If I set it to ByContainer I get this error: 15:14:02,562 WARN [JBossManagedConnectionPool] Destroying connection that could not be successfully matched: underline>color>param>1999,1999,/param>org.jboss.resource.adapter.jdbc.xa.oracle.XAOracleManagedConnection@462631 /color>/underline>And connection still Opened on the DB. Could you please explain me what's happen. Thank you in advance BTW I attached my source, what about it? Couldn't it be useful for anyone? /excerpt>image.tiff> excerpt> OracleServerLoginModule.java>/excerpt> image.tiff>
Re: [JBoss-dev] RE: Are you in functional programming and JSR94? How can I join this?
I'm very interested in what you have in mind for a rules engine. I once integrated JEOPS into jboss as an interceptor: ejb invocations are supplied to the rules engine on the way down and on return. I made some experiments, for instance the rules could compute a transitive closure. The original implementation won't work with current jboss, I have a partially functional replacement (this is currently inaccessible due to hardware problems, but I hope it will be recoverable). I'd love to collaborate on getting it to work again if you are interested. Do you know of JEOPS (sourceforge)? It was the only rules engine I could find that had a reasonable license. I also think that the future of programming will more and more involve reliance on declarative/functional approaches, especially to glue together procedural code snippets. thanks david jencks On Friday, January 31, 2003, at 10:03 AM, Bill Burke wrote: Hope you don't mind, but I have the [jboss-dev] mail list in copy. What I think you're saying in all your email is: 1. You're interested in Rules engines and JBoss (jsr94) 2. You want to fuse AOP and a Rules engine. Both are great ideas. We're always looking for people with initiative and new exciting ideas. How can you join this? Implement something. Implement something that sort of works, and we'll give you CVS access. We're pretty free with CVS access as long you have shown some prior initiative. I think a Rules engine would be an excellent addition to JBoss and I am looking forward to your contributions. Let us know. Best Regards, Bill Burke Chief Architect JBoss Group, LLC -Original Message- From: Tomas Lapienis [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 30, 2003 7:58 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Are you in functional programming and JSR94? How can I join this? This letter is basically provoked by Bill's call for developers :) Hello Marc and Bill, I want to join JBoss development in the area which I think is the key area in the modern programming technologies. Actually for me it was a missing part which I was looking for years and (stupid me:-) successfully overlooked - until a few month ago. In the first glance it looks as simple as jsr94 http://www.jcp.org/ja/jsr/detail?id=94 But for me it is not just one more API in a growing J2EE technology set. (BTW, BEA is involved ;-) I see funtional programming as a glue for Aspects. CV I have 16 years of experience in programming (10 years I was paid for that). I have started from procedural (Pascal); then it was x86 assembler under DOS next I did OO in C++; device drivers in C; let myself to express in 100 lines of single sql statement in oracle (this requires futher explanation); felt advanced in C++ STL Generic and Design Patterns; got some java; hacked own XSLT based on W3 draft under Java and some lib for servleting it (Cocoon style embryo); [this is the part when I saw EJBoss for the first time - year 2000]; next years I spent under strong influence of Apache and JBoss doing Web Apps - I could not be fast enough with growing good technologies set - especialy Apachy's ones. /CV And I feel puzzled in Apache - there are a bunch of nice technologies which does more or less the same but is difficult to mix and match. So I bounded myself to a very basic (IMHO) technologies and started to look up for the glue. Aspects were looking very promising [glue] except that Aspects ran into the problem - there is the need for query language which will resolve the problem how to apply (mixmatch) aspects on the system. I kept thinking until I noticed functional approach to all this procedural nightmare. I started to dig deeper and that's what I noticed: Functional Approach (FnA) a) FnA is a kind of technology which now has a little effort made to combine it with Procedural Approach (in open source area especialy). BTW, Messaging System is a kind of stripped FnA (IMHO) b) I think that extended treatment of FnA will work as a glue for Aspects. Also, FnA cuts the need for aspects!!! They become a Rhs of FnA. OK, I'm wrong here :) in FnA Aspects remains as a powerful Design Patterns Set for Problem Solving. Anyway, current FnA lacks of delegation which is required part when doing distributed applications - some business logic must be applied on remote data IN THE remote site without additional coding. Resume: This is introductory part - I need feedback about JBoss Community interests and advances in FnA field. Mail me directly or tell what mailing lists to subscribe (currently this account is not subscribed to any) Regards, Tomas Lapienis P.S. Many things left not said: one of them is my study in oracle performance - rule based optimization and cost based optimization (spent 1 year full time) It discusses throughput - goes with explanation why it has 100 lines in single sql statement. BTW, EJB fundamentals clashes with this experience - the partial work
Re: [JBoss-dev] RE: Are you in functional programming and JSR94? How can I join this?
I'm looking now, this is very interesting! Thanks! david jencks On Friday, January 31, 2003, at 11:30 AM, Kevin Conner wrote: Do you know of JEOPS (sourceforge)? It was the only rules engine I could find that had a reasonable license. Did you look at mandarax? Kev Kevin Conner This is a personal e-mail. Any views or opinions presented are solely those of the author and do not necessarily represent those of Orchard Information Systems Ltd. --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Accessing Container from an EJB?
I'm pretty confused about what exactly you are trying to do, since there is already an instance variable ejbModule and and accessors get/setEjbModule in the Container class. ?? david jencks On Thursday, January 30, 2003, at 01:36 AM, Jeremy Boynes wrote: I am trying to write an EJBTestCase that needs access to information held in the Container (Container.getEjbModule().getModuleData(CATALOG)). I can do this if I add EjbModule as a attribute of Container but was wondering if I should do this or if there was another way? Thanks Jeremy --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
