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 /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.(XMBean.java:214) [java] at org.jboss.mx.modelmbean.XMBean.(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 xxx
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.(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
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 =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://##. 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 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 =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://##. 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
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 =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://##. 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 =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://##. 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 > > > > > > > > ServiceController "Invalid transition from..." > > > > > Are these > messages new? What do they mean? T LANG="en-us">hey are > all over the place LANG="en-us"> in JB4 LANG="en-us"> and I > don SIZE=2 FACE="Arial">’ LANG="en-us">t recall seeing them > before. LANG="en-us"> > > 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, LANG="en-us"> FACE="Arial">invalid transition from CREATED LANG="en-us"> > > FACE="Arial">… LANG="en-us"> > > 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, LANG="en-us"> FACE="Arial">invalid transition from state RUNNING LANG="en-us"> > > 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, LANG="en-us"> FACE="Arial">invalid transition from state LANG="en-us"> > CONFIGURED LANG="en-us"> > > FACE="Arial">… LANG="en-us"> > > 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, LANG="en-us"> FACE="Arial">invalid transition from state LANG="en-us"> FACE="Arial"> LANG=
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 s
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] 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] 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) > >&
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] >
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 retu
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.i
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=detail&atid=381174&aid=712495&group_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] 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: > > > Pi is a read-only attribute added at the metadata > level > for which there is no state in the User2 instance. > > Pi > double > > > > > > > only the 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] 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
[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?
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
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.(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] JBoss-3.2 build issues
did you check out -r Branch_3_2 jboss-3.2
david jencks
On 2003.03.18 09:40 Alex Loubyansky wrote:
> I did a clean check out of jboss-3.2 and can't build it on Win2000
> with Sun's jdk1.3.1.
> I have no idea what's wrong. Whether it's something wrong with my
> environment or it is check out incorrectly, though I re-checked out it
> again. Any hints are welcome.
>
> The problem is with classpath.
> I had to correct local.properties
> #xdoclet.xdoclet.root=${project.root}/thirdparty/xdoclet-xdoclet
> xdoclet.xdoclet.root=${project.root}/thirdparty/xdoclet/xdoclet
> and other paths from vendor-jarname to vendor/jarname as it appears in
> checked out dir structure.
> I didn't fix all the problems yet. Any hints?
>
> Thank you,
> alex
>
>
>
>
> ---
> This SF.net email is sponsored by: 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: 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] The recent OSX 1.4.1/XDoclet problem
On 2003.03.17 09:36 Lennart Petersson wrote: > Was Mr. Jencks's fix only for head? yes, the xdoclet versions used with 3.0 and 3.2 are truly antiques. I'm still scared to upgrade to the released apple 1.4.1. Has anyone else had this problem building 3.0/3.2? Upgrading to a more current xdoclet is some work. It involves at least changing all the build files to not specify sourcepath, and may require significant work to explicitly import all classes in source files (rather than import blah.*;). I think Scott would have to OK changing the 3.0 build. david jencks Because I get problems when building > 3.0/3.2 also. Here is output from 3.0: > > compile-mbean-sources: > [mkdir] Created dir: > /Users/lepe/projects/JbossSources/jboss-3.0/common/output/gen-src > sourcepath is deprecated. the preferred way to design sources is via > nested > Running xdoclet.XDocletMain loaded by sun.misc.Launcher$AppClassLoader. > Forked:true >[xdoclet] Running >[xdoclet] Generating output for > 'org.jboss.util.property.jmx.SystemPropertyClassValue' using template > file > 'jar:file:/Users/lepe/projects/JbossSources/jboss-3.0/tools/lib/ > xdoclet.jar!/xdoclet/jmx/mbean.j'. >[xdoclet] Running XDoclet failed >[xdoclet] <> >[xdoclet] java.lang.RuntimeException: Error running XDoclet >[xdoclet] at xdoclet.XDocletMain.start(XDocletMain.java:77) >[xdoclet] at xjavadoc.ant.XJavaDocMain.main(XJavaDocMain.java:94) > > Using OSX jdk 1.4.1 official release and latest 3.0 > > /L > > > > --- > 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... [object name or another mbean dd] and [o-n or mbean dd] [o-n or mbean dd] ... 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
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] 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] 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. 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. 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? 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
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/JNDIDetectorTe
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 125>jar -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 > xxxx > > - 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] 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] 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] 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 sus
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: 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.ServerSessionPo
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 >
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 > xxxxxxxx > > - 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. >
[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
[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] 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
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 includ
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
[JBoss-dev] (jb4) Change to session bean's UserTransaction -- is it OK?
After studying the previous implementation of UserTransaction for BMT session beans I have eliminated it in favor of the standalone implementation. If, after reading the explanation below, anyone knows of a reason this might not work, please speak up. The only function I could see to the session bean specific implementation was to clear the context's transaction when the user transaction was ended. This transaction variable is used to re-enroll BMT stateful session beans in the correct transaction when a tx is started in one method call and ended in another. On the way out from the first method call the tx is stored in the ctx and on the way in the tx is resumed. There was a comment to the effect that the tx needed to be cleared so that later calls wouldn't try to enroll in an ended transaction. I have replaced this code by code that always sets the context's transaction to the current transaction: if the transactio has ended this is null. AFAIK the only possible difference in behavior between the previous code and my replacement would be if the session bean could call itself between ending the transaction and returning. However, session beans are non-reentrant so this cannot happen. I also replaced the somewhat complicated code to supply the correct context's UserTransaction when java:/comp/env/UserTransaction is looked up with a simple linkref to the global UserTransaction. Again, if anyone sees any problem with this please speak up. 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] 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: [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] 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: 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: > > > > > 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
Maybe we're confusing 2 issues here: 1. writing a maintainable usable jboss dtm 2. supporting corba etc. I realize I am not entirely comfortable with the client interceptors, and I notice that they are not really used in the local proxies. I don't think my idea of using the client interceptors inside a corba invoker will work, because there will be no way to simulate a client environment. So I'm basically abandoning my idea of always using the same client interceptors for all clients including local, remote, and corba. I think the current client interceptor stack configuration system may be lousy and need redesign, but that is sort of a third question. I think it should not be tied to the invoker but to local/remote/corba choice. The fact that all client interceptor stacks today are identical supports this view. How about: server side interceptor gets back the functionality of suspending transactions that are not needed (for not supoorted and requires new) client side interceptor for remote client does this also, to avoid creating unneeded branches. Local clients won't need the client side tx interceptor. The corba clients will continue creating branches based on the corba transaction policy, and we will import all such transactions that arrive via corba immediately. The server side tx interceptor may suspend these tx in the case of notsupported and requiresNew. There's nothing we can do about the remote corba tm creating unneeded branches, and the simplest way to deal with them is simply to import them so when a prepare/commit/etc request comes we just let our tm deal with it. - (in reference to Hiram's comment) On the client side, I need 2 pieces of functionality: a tx-support aware interceptor per remote object (ejb name, not instance) and an xaresource per remote jboss server. I'm still convinced this is by far the simplest possible implementation for dtm. I think writing the xaresource as a transport-level interceptor will have many many simplifying advantages, but it is not necessary, only about half as complex as my previous solution. It could be written once and plugged in some other way, but I don't see the point in using an inferior architecture to an interceptor stack. Thanks david --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread
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 chain
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, &
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
; 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 &g
RE: [JBoss-dev] org.jboss.aop.MethodMetaData
On 2003.02.24 14:25 Bill Burke wrote: > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Behalf Of > David > > Jencks > > Sent: Monday, February 24, 2003 1:54 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] org.jboss.aop.MethodMetaData > > > > > > On 2003.02.24 13:17 Bill Burke wrote: > > > > > > > > > > -Original Message----- > > > > From: [EMAIL PROTECTED] > > > > [mailto:[EMAIL PROTECTED] Behalf Of > > > David > > > > Jencks > > > > Sent: Monday, February 24, 2003 10:37 AM > > > > To: [EMAIL PROTECTED] > > > > Subject: RE: [JBoss-dev] org.jboss.aop.MethodMetaData > > > > > > > > > > > > > > > > > > > > > I also want to add that the current interface for Metadata, > metadata > > > > > chains, > > > > > and how you configure metadata is open for debate. It probably > is > > > not a > > > > > complete definition and I'm open for suggestions. I'm > > hoping that as > > > I > > > > > port > > > > > some of the current interceptors more requirements will be > flushed > > > out. > > > > > Persistence will be the big test. > > > > > > > > I don't have any very solid ideas yet, but I think these would be > > > > improvements: > > > > > > > > 1. Single level lookups with Object keys rather than String: Object > > > > getMetadata(Object key). Why force the guy storing the > > metadata to use > > > a > > > > concealed hashmap with String keys? > > > > > > > > > > Why? Simplicity. But fair nuff. > > > > > > > 2. Put the default metadata in the thing that supplies the chain of > > > > interceptors (Advisor?), and always add it first to what the > > Invocation > > > > gets. (rather than putting the default metadata in the Invocation > > > > directly. > > > > > > > > > > Advisor does not work the way you describe it. The Advisor creates > an > > > ArrayList of MetaData repositories(the chain) and passes it as a > > > parameter > > > to the Invocation object. The Invocation object is itself a > > > MetadataResolver and is first in the chain. > > > > Can you explain why the invocation object has this unique metadata > object > > rather than always getting it from the advisor? Is this how you want > to > > support customization of individual invocations? But where does the > > invocation come from? How will it get this unique metadata? > > > > Invocation object has unique metadata for tx and security propagation for > example. If there is no txid or security credentials to pass, this > object > is empty. Think of it as the payload in the old invocation object. The > Invocation object has unique metadata so that interceptors can pass on > information farther along the chain. > > This is not how I will support customization of individual invocations. > I > have a ThreadMetaData object that is second in the chain. ThreadMetaData > class simply uses a ThreadLocal to hold SimpleMetaData. > > So the chain looks like this currently: > > Invocation, ThreadMetaData, InstanceAdvisor.metadata, > ClassAdvisor.MethodMetaData, ClassAdvisor.defaultmetadata. Aha! At least there's something we can agree on! I like this, now I understand, good idea, etc. etc. Thanks. I missed this reading the code. > > As far as remoting goes. The SimpleMetaData class does have the means > now > to define whether data should be serialized across the wire. My thought > is > that when a DP (and later an AOP'ized Class") is serialized, my thoughts > are > that the the serializer will again walk through the chain and ask each > repository for its serializable data. Or another possibility is that the > Interceptor knows which metadata should be serialized. This area needs > some > thought and iteration. At the moment I'd think that having a single level metadata repository and having the items you store in it know how and if to serialize themselves would make sense. Or using non-string keys that indicate if the value is transient is another possibility. > > Am I making sense? If not, I'll elaborate. > > > I'd think that giving the "top of the chain" object the default > metadata > > and then providing some facility for pulling more in from
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
RE: [JBoss-dev] org.jboss.aop.MethodMetaData
On 2003.02.24 13:17 Bill Burke wrote: > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Behalf Of > David > > Jencks > > Sent: Monday, February 24, 2003 10:37 AM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] org.jboss.aop.MethodMetaData > > > > > > > > > > > I also want to add that the current interface for Metadata, metadata > > > chains, > > > and how you configure metadata is open for debate. It probably is > not a > > > complete definition and I'm open for suggestions. I'm hoping that as > I > > > port > > > some of the current interceptors more requirements will be flushed > out. > > > Persistence will be the big test. > > > > I don't have any very solid ideas yet, but I think these would be > > improvements: > > > > 1. Single level lookups with Object keys rather than String: Object > > getMetadata(Object key). Why force the guy storing the metadata to use > a > > concealed hashmap with String keys? > > > > Why? Simplicity. But fair nuff. > > > 2. Put the default metadata in the thing that supplies the chain of > > interceptors (Advisor?), and always add it first to what the Invocation > > gets. (rather than putting the default metadata in the Invocation > > directly. > > > > Advisor does not work the way you describe it. The Advisor creates an > ArrayList of MetaData repositories(the chain) and passes it as a > parameter > to the Invocation object. The Invocation object is itself a > MetadataResolver and is first in the chain. Can you explain why the invocation object has this unique metadata object rather than always getting it from the advisor? Is this how you want to support customization of individual invocations? But where does the invocation come from? How will it get this unique metadata? I'd think that giving the "top of the chain" object the default metadata and then providing some facility for pulling more in from the environment would make sense. My impression is that your Advisor object is the top of the interceptor chain. Is thie correct or wrong? The Invocation object does > not > have amashed down, merged set of metadata. I didn't say it should. But for sure it should conceal how it looks up the metadata from the guys who are asking for it. The Invocation only has a > reference to the repositories not a copy of each metadata element. I > don't > know if this is a good analogy, but I think of it as polymorphic data. > > > I have some code with these ideas, I'll try to commit it or send > > it to you > > later today. > > > > I think it will take some experimentation to get something that works > > really well. > > > > I agree. I want this chaining, but am open to the implementation. fine david > > Bill > > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread
On 2003.02.24 11:22 Sacha Labourey wrote: > Hello David, > > > I tend to regard the functionality in client interceptors as really > > required to make anything work. I agree that chain/invoker > > is excessive. > > I think we need the same client side interceptor stack no > > matter what the > > transport. For java clients, these interceptors will really > > live on the > > client. For non java-clients, they will be somewhere inside > > the server > > side of the transport mechanism. > > My guess is that for non-java client, we will (in almost all cases) not > decide what can be done on the client side. Consequently, it will most > probably be the role of the server side invoker to populate the > Invocation > object with additional "well-known-attributes" that are directly > extracted > from the "context" of this specific transport (and not by some > jbossish-client-interceptor as they won't exist in this case) I think, then, that we agree that the functionality implemented by client-side interceptors is not optional but required. I was proposing for simplicity and flexibility that we always implement this functionality with the same code: for non java clients, we have to run these client side interceptors on the server, and the specific transport will have to provide an environment equivalent to the java client environment so that the "client" interceptors can still work. Since we can't really control which client interceptors people will want to use, I don't think we can hardcode the client interceptor functionality into the transport specific code. david > > > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] TxInterceptor split is still the best thing since sliced bread
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
RE: [JBoss-dev] org.jboss.aop.MethodMetaData
> I also want to add that the current interface for Metadata, metadata > chains, > and how you configure metadata is open for debate. It probably is not a > complete definition and I'm open for suggestions. I'm hoping that as I > port > some of the current interceptors more requirements will be flushed out. > Persistence will be the big test. I don't have any very solid ideas yet, but I think these would be improvements: 1. Single level lookups with Object keys rather than String: Object getMetadata(Object key). Why force the guy storing the metadata to use a concealed hashmap with String keys? 2. Put the default metadata in the thing that supplies the chain of interceptors (Advisor?), and always add it first to what the Invocation gets. (rather than putting the default metadata in the Invocation directly. I have some code with these ideas, I'll try to commit it or send it to you later today. I think it will take some experimentation to get something that works really well. david > > Bill > > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] org.jboss.aop.MethodMetaData
On 2003.02.24 09:14 Bill Burke wrote:
>
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] Behalf Of
> David
> > Jencks
> > Sent: Saturday, February 22, 2003 1:43 PM
> > To: [EMAIL PROTECTED]
> > Subject: [JBoss-dev] org.jboss.aop.MethodMetaData
> >
> >
> >public Object resolve(Invocation invocation, String group, String
> attr)
> >{
> > Method method = MethodInvocation.getMethod(invocation);
> > return getMethodMetaData(method.getName(), group, attr);
> >}
> >
> > Am I missing something or is this code making the assumption that a
> > method's name provides sufficient discrimination amongst all possible
> > method metadata? If so, what is the architectural rationale behind
> that
> > usage?
> >
>
> EJB metadata does not take into account method arguments either.
???
Some ejb metadata appears to:
from ejb_jar_2_1.xsd, inside methodType, around line 1639
3.
EJBNAME
METHOD
PARAM-1
PARAM-2
...
PARAM-n
This style is used to refer to a single method within a
set of methods with an overloaded name. PARAM-1 through
PARAM-n are the fully-qualified Java types of the
method's input parameters (if the method has no input
arguments, the method-params element contains no
method-param elements). Arrays are specified by the
array element's type, followed by one or more pair of
square brackets (e.g. int[][]).
[david-- there appears to be a mistake in the xsd, copying the last
sentence of style 2 at this point]
Whidh ejb metadata are you referring to?
david
>
> Bill
>
>
>
> ---
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [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.s
[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 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 iter
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
On 2003.02.21 18:58 Bill Burke wrote: > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Behalf Of > Hiram > > Chirino > > Sent: Friday, February 21, 2003 6:44 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] TxInterceptor split is really really bad > > > > > > > > --- Bill Burke <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > I would like to note that my future plans for this > > > involve method specific > > > > interceptor chains with a variety of "client side" > > > and "server side" tx > > > > interceptors, each one performing half of the > > > TxSupport work. No maps, > > > > just different specialized interceptors, with > > > different interceptors per > > > > method depending on the tx support. > > > > > > > > > > H...thanks for mentioning this. The AOP > > > framework will have to change > > > to support his type of per method intercepiton. > > > > > > Currently the ClassAdvisor asks the > > > InterceptorFactory for an instance of an > > > Interceptor and adds it to the interceptor chain. > > > For what you want to do, > > > this will have to change. The InterceptorFactory > > > should be responsible for > > > adding interceptors to the chain. Otherwise, my > > > isolation and separation of > > > metadata, interceptors, and pointcuts will be > > > broken. > > > > > > > I don't think that you model would be too broken. > > His interceptors should only hav to implement the > > org.jboss.aop.InvocationFilterInterceptor interface: > > boolean intercepts(Invocation invocation); > > > > The org.jboss.aop.Invocation.invokeNext() will skip > > over interceptors that do not interested the > > invocation. Currently invokeNext() interogates the > > intercetors on every invocation, but I think that we > > should be able to keep a per Invocation interceptor > > stack cache so that we can skip the interogation after > > the first method call. Per method interceptor stacks will eliminate the need to the interceptor filter interface. > > > > That's not the issue. The issue is configuration. He wants to avoid > sending over metadata about the method/tx bindings. WTF??? I want to send to the client the information about whether an exising tx needs to be sent, and as I have indicated I would like to encode this in which interceptor is in each method's client side invocation chain. Until we have method specific interceptor chains, I need a method to tx support map. TO do this he > creates a > Mandatory.java class and attaches it to the method. You see now? > > Actually David, you actually have almost the same memory footprint. As what??? > WIthout > per method , you have one instance of the Tx interceptor. WIth, you have > an > instance per interceptor. Almost the same as a hashmap of methodnames > and > strings identifying the tx attribute. yes, this is obvious. Maybe we have really different ideas about what will go in the interceptor stack for an aop object. I was assuming that it would go like this, just like an ejb: local aop object > ci1 > ci2 > "local invoker" > si1 > si2 > si2 > actual aop object and remote aop object > ci1 > ci2 > real invoker (transport) > si1 > si2 > actual aop object where ci are client interceptors and si are server interceptors. This way any aop object gets the same interceptor stack no matter if it is local or remote. I don't really care if either the local or remote aop object is the actual object or some kind of proxy: I don't think it makes any difference. I don't see why the remote aop thingy can't be the actual object rather than a dynamic proxy, it's just that all the work gets tossed over to a different server. If you plan to leave out the ci's for local aop objects I want to know how you have any chance of getting even mildly similar behavior between local and remote versions. === corba My current (limited) understanding of corba tx support leads me to believe that any working corba implementation will use the corba tx policies to their fullest advantage and will have already established and enlisted a transaction branch on the corba tx manager whenever it sends a transaction with an invocation. We can't do anything about this, so we can't save it some work if it happens to be calling a method (not supported or requires new) that won't use the tx that was sent. I assume we can't install any kind of real client side interceptors in corba, we just have to take what is sent to us. If this is wrong please speak up. Therefore, we have to duplicate the functionality of the client side interceptors somewhere on the server side in the iiop invoker. If we don't do this we will get the wrong semantics. I don't know exactly how the iiop invoker works, but I would hope that we could set it up so that it looks like: outside world >>> something corba and proxy-like > ci1 > ci2 > some kind of invoker-like thing > si1 > si2 > actual target object This is really sim
RE: [JBoss-dev] 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 t
[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] 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) > > > > > > > > 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
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 > > > > > > > Message > > > > 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 ca
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] 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 repositor
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:
>
>:loader=compA
>
>
> jboss-app of B:
>
>
> loaderRepositoryClass="org.jboss.mx.loading.DelegatingLoaderRepository"
> objectName=":loader=compB"
> >:loader=compA
>
>
> 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:
>
>
> loaderRepositoryClass="org.jboss.mx.loading.DelegatingLoaderRepository"
> objectName=":loader=compC"
>
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,
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] TxInterceptor split is really really good
On 2003.02.17 04:20 Ole Husgaard wrote: > Hi, > > 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. IMO this results in an easier to understand system with more appropriate division of responsibilities. The xid which I am using as the transportable transaction identifier is only available from the client side after the registration callback if the client is a JTA environment. > > 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. > 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. 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. > > 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. > 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. And the resource registration occurs on the return of the original method invocation, or does it take an extra round trip immediately? The former incurs redundant bookkeeping requirements and the latter is inefficient. thanks david jencks > > Best Regards, > > Ole Husgaard. > > > 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
[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] 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 > xxxx > > - 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
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
> > > > __
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] 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] 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] 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
> > > >
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 > > > > > > > > > RE: [JBoss-dev] is head all messed up? > > > > 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"; > TARGET="_blank">http://java.sun.com/dtd/connector_1_0.dtd Nested > exception: Server returned HTTP response code: 403 for URL: HREF="http://java.sun.com/dtd/connector_1_0.dtd"; > TARGET="_blank">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 [ HREF="mailto:[EMAIL PROTECTED]";>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&#x
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] 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: > > > > > >> type="java.lang.NullPointerException">java.lang.NullPointerExcepti > > on at > > org.jboss.media.JBossMediaUnitTestCase.createFileFromResource(JBos > > sMediaUnitTestCase.java:196) at > > org.jboss.media.JBossMediaUnitTestCase.setUp(JBossMediaUnitTestCas > > e.java:61) > > > > > >> type="java.lang.NullPointerException">java.lang.NullPointerExcepti > > on at > > org.jboss.media.JBossMediaUnitTestCase.createFileFromResource(JBos > > sMediaUnitTestCase.java:196) at > > org.jboss.media.JBossMediaUnitTestCase.setUp(JBossMediaUnitTestCas > > e.java:61) > > > > > >> type="java.lang.NullPointerException">java.lang.NullPointerExcepti > > on at > > org.jboss.media.JBossMediaUnitTestCase.createFileFromResource(JBos > > sMediaUnitTestCase.java:196) at > > org.jboss.media.JBossMediaUnitTestCase.setUp(JBossMediaUnitTestCas > > e.java:61) > > > > > > *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
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] 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] Why are we using this bogus construct
On 2003.02.13 14:42 Larry Sanderson wrote:
> ... ...
>
> 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 synchroniza
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()
> >>{
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
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] 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 s
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
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] 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] OracleLoginModule
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 --- 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
