RE: [JBoss-dev] XSLSubDeployer improvements and jca 1.5 mdb deployment
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David Jencks Sent: Monday, June 16, 2003 12:32 AM To: [EMAIL PROTECTED] Subject: [JBoss-dev] XSLSubDeployer improvements and jca 1.5 mdb deployment I've modified the deployment system to allow for multiple xml deployment descriptors. XSLSubDeployer can be configured via the Properties valued DdNameToKeyMap property to import the specified dds and store them in the DeploymentInfo under the specified key. The properties lines look like dd-name=KEY. I've also added the new DeploymentInfoURIResolverFactory which can resolve uris to documents in the current deployment info or documents in other DeploymentInfo mbeans. URIs are of the form jboss-di://deployment-info-name#key#xpath expression. The deployment-info-name and xpath-expression are optional. The DeploymentInfoDocumentURIResolver is now obsolete. I've discovered that use of two # characters in a URI is ungrammatical so the first will be changed to ! shortly. If we're moving to a meta object model, please tell me why we need point pointers into the documents of different deployments? 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
Re: [JBoss-dev] XSLSubDeployer improvements and jca 1.5 mdb deployment
On Monday, June 16, 2003, at 10:57 PM, Bill Burke wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David Jencks Sent: Monday, June 16, 2003 12:32 AM To: [EMAIL PROTECTED] Subject: [JBoss-dev] XSLSubDeployer improvements and jca 1.5 mdb deployment I've modified the deployment system to allow for multiple xml deployment descriptors. XSLSubDeployer can be configured via the Properties valued DdNameToKeyMap property to import the specified dds and store them in the DeploymentInfo under the specified key. The properties lines look like dd-name=KEY. I've also added the new DeploymentInfoURIResolverFactory which can resolve uris to documents in the current deployment info or documents in other DeploymentInfo mbeans. URIs are of the form jboss-di://deployment-info-name#key#xpath expression. The deployment-info-name and xpath-expression are optional. The DeploymentInfoDocumentURIResolver is now obsolete. I've discovered that use of two # characters in a URI is ungrammatical so the first will be changed to ! shortly. If we're moving to a meta object model, I'm not convinced we are, I am unconvinced anything more than mbeans is necessary. Configuring mbeans that do the work directly has the nice property that you can see and change what the properties are directly in the jmx console. please tell me why we need point pointers into the documents of different deployments? This has been there since the beginning of jb4. The ra.xml from an adapter is transformed into xmbean descriptors, which need to be included or accessed somehow when an mbean based on one of them is deployed, i.e. when a connection factory is deployed. The change I just made is to let you get to more than one xml doc in a single deployment info, something the current metadata classes do in hardcoded java. BTW, I am not completely thrilled with the complexity of the xsl stylesheets I'm currently using and am looking for something simpler. Apache Commons Digester looks like a possibility. david Bill --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] XSLSubDeployer improvements and jca 1.5 mdb deployment
On Tuesday, June 17, 2003, at 12:58 AM, Bill Burke wrote: Not sure I like this idea. Tell me why we need to support 3.2 and 3.0 descriptors in 4.0? I'd much rather a 3.2 component crap out gracefully in 4.0 than have to maintain 3 separate configuration mechanisms. I wish we could get rid of the old stuff, but it is a requirement of the EJB 2.1 specification that we support 2.0 and 1.1 deployment descriptors. Also, one of the common complaints of the JBoss project is the changing of deployment descriptors and the lack backward compatibility. With XSL we can build the code to support on version and use style sheets to up convert old stuff. I do like the idea of having a metamodel separate from XML parsing. BUT STILL, it is quite easy to navigate the current metadata/XML marriage that now exists in current configuration. Are you sure we're actually gaining any maintainability by changing the status quo? I thought one of Scott's requirements was to remove reliance on XML in the metadata model for 4.0. Scott? -dain --- 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 Tuesday, June 17, 2003, at 12:36 AM, Bill Burke wrote: Why? Because everybody is very familiar with them. Why? because its simple and easy to maintain and modify. Yes, the XML parsing needs to be moved to a separate module, but the classes themselves have held up fine. I will not allow you to add anything overly complex like the mess you did with datasources. David, you have never ever built a piece of software for JBoss that was even remotely intuitive to configure. Configuration is not your strength so please STAY AWAY from it. I'm warning you. If I see an XSLT translation anywhere within EJB land I will roll it back. Can we please dial back the personal and emotional issues and return to objective discussions of the technology? -dain --- 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
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Dain Sundstrom Sent: Tuesday, June 17, 2003 2:35 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] XSLSubDeployer improvements and jca 1.5 mdb deployment On Tuesday, June 17, 2003, at 12:36 AM, Bill Burke wrote: Why? Because everybody is very familiar with them. Why? because its simple and easy to maintain and modify. Yes, the XML parsing needs to be moved to a separate module, but the classes themselves have held up fine. I will not allow you to add anything overly complex like the mess you did with datasources. David, you have never ever built a piece of software for JBoss that was even remotely intuitive to configure. Configuration is not your strength so please STAY AWAY from it. I'm warning you. If I see an XSLT translation anywhere within EJB land I will roll it back. Can we please dial back the personal and emotional issues and return to objective discussions of the technology? XSLT translations in EJB land will be rolled back. 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
RE: [JBoss-dev] XSLSubDeployer improvements and jca 1.5 mdb deployment
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Dain Sundstrom Sent: Tuesday, June 17, 2003 2:32 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] XSLSubDeployer improvements and jca 1.5 mdb deployment On Tuesday, June 17, 2003, at 12:58 AM, Bill Burke wrote: Not sure I like this idea. Tell me why we need to support 3.2 and 3.0 descriptors in 4.0? I'd much rather a 3.2 component crap out gracefully in 4.0 than have to maintain 3 separate configuration mechanisms. I wish we could get rid of the old stuff, but it is a requirement of the EJB 2.1 specification that we support 2.0 and 1.1 deployment descriptors. Also, one of the common complaints of the JBoss project is the changing of deployment descriptors and the lack backward compatibility. With XSL we can build the code to support on version and use style sheets to up convert old stuff. I do like the idea of having a metamodel separate from XML parsing. BUT STILL, it is quite easy to navigate the current metadata/XML marriage that now exists in current configuration. Are you sure we're actually gaining any maintainability by changing the status quo? I thought one of Scott's requirements was to remove reliance on XML in the metadata model for 4.0. Scott? I would rather have a separate migration tool than to actually provide the ability to deploy older versions of JBoss. Or even better, deployers that actually tell you what is wrong with the XML you're deploying rather than getting some barf from a DTD validator or XSL transformer. Old code should be getting simpler and smaller with age as it gets refactored. I get a little wary when I see people writing abstractions for the simplest of things. Bill -dain --- 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
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David Jencks Sent: Tuesday, June 17, 2003 2:16 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] XSLSubDeployer improvements and jca 1.5 mdb deployment On Monday, June 16, 2003, at 10:57 PM, Bill Burke wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David Jencks Sent: Monday, June 16, 2003 12:32 AM To: [EMAIL PROTECTED] Subject: [JBoss-dev] XSLSubDeployer improvements and jca 1.5 mdb deployment I've modified the deployment system to allow for multiple xml deployment descriptors. XSLSubDeployer can be configured via the Properties valued DdNameToKeyMap property to import the specified dds and store them in the DeploymentInfo under the specified key. The properties lines look like dd-name=KEY. I've also added the new DeploymentInfoURIResolverFactory which can resolve uris to documents in the current deployment info or documents in other DeploymentInfo mbeans. URIs are of the form jboss-di://deployment-info-name#key#xpath expression. The deployment-info-name and xpath-expression are optional. The DeploymentInfoDocumentURIResolver is now obsolete. I've discovered that use of two # characters in a URI is ungrammatical so the first will be changed to ! shortly. If we're moving to a meta object model, I'm not convinced we are, I am unconvinced anything more than mbeans is necessary. Configuring mbeans that do the work directly has the nice property that you can see and change what the properties are directly in the jmx console. That's a nifty idea, but until we get a JMX console that can display hierarchical data, pretty much useless. I'd like to see a better scheme to render the current JMX components before this idea is explored. 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
Re: [JBoss-dev] XSLSubDeployer improvements and jca 1.5 mdb deployment
Its a simply ease of use argument. Why should I have to go through a conversion step if this can be handled by the deployment process. The current XML/metadata parsing is not maintainable. Changes are made that are not reflected in the schemas which make it difficult for tools to follow JBoss. Deployment descriptors also become non-validatable. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Bill Burke [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, June 16, 2003 10:58 PM Subject: RE: [JBoss-dev] XSLSubDeployer improvements and jca 1.5 mdb deployment Not sure I like this idea. Tell me why we need to support 3.2 and 3.0 descriptors in 4.0? I'd much rather a 3.2 component crap out gracefully in 4.0 than have to maintain 3 separate configuration mechanisms. I do like the idea of having a metamodel separate from XML parsing. BUT STILL, it is quite easy to navigate the current metadata/XML marriage that now exists in current configuration. Are you sure we're actually gaining any maintainability by changing the status quo? 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
Re: [JBoss-dev] XSLSubDeployer improvements and jca 1.5 mdb deployment
An mbean is still an object metamodel. Exposing this as an mbean is a seperate issue. Scott Stark Chief Technology Officer JBoss Group, LLC 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 --- 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
A deployer that tells you what is wrong with the xml is a schema validator. There is no reason to embed this functionality in the deployers, use an xml schema and let the xml to object transform handle the validation. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Bill Burke [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, June 17, 2003 1:09 AM Subject: RE: [JBoss-dev] XSLSubDeployer improvements and jca 1.5 mdb deployment I would rather have a separate migration tool than to actually provide the ability to deploy older versions of JBoss. Or even better, deployers that actually tell you what is wrong with the XML you're deploying rather than getting some barf from a DTD validator or XSL transformer. Old code should be getting simpler and smaller with age as it gets refactored. I get a little wary when I see people writing abstractions for the simplest of things. 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
Re: [JBoss-dev] XSLSubDeployer improvements and jca 1.5 mdb deployment
We should be looking at jaxb driven by schemas for the metadata parsing before considering the commons digester framework. I'm looking at jaxb for inclusion in the 3.2 branch to address some stability issues. Scott Stark Chief Technology Officer JBoss Group, LLC --- 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
Hi David, Did you forget to commit stylesheets/JMSMDBTemplate.xsl? Regards, Adrian Adrian Brock Director of Support Back Office JBoss Group, LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Jencks Sent: 16 June 2003 05:32 To: [EMAIL PROTECTED] Subject: [JBoss-dev] XSLSubDeployer improvements and jca 1.5 mdb deployment I've modified the deployment system to allow for multiple xml deployment descriptors. XSLSubDeployer can be configured via the Properties valued DdNameToKeyMap property to import the specified dds and store them in the DeploymentInfo under the specified key. The properties lines look like dd-name=KEY. I've also added the new DeploymentInfoURIResolverFactory which can resolve uris to documents in the current deployment info or documents in other DeploymentInfo mbeans. URIs are of the form jboss-di://deployment-info-name#key#xpath expression. The deployment-info-name and xpath-expression are optional. The DeploymentInfoDocumentURIResolver is now obsolete. I've discovered that use of two # characters in a URI is ungrammatical so the first will be changed to ! shortly. I've simplified the ejb container mbeans to remove common code to the Container class and allow deployment of MDBs with arbitrary interfaces per the ejb 2.1 spec. However, only jms MessageListener MDBs can be deployed at the moment. Deployment proceeds by constructing and deploying an ActivationSpec xmbean instance from the ejb 2.0 mdb dd. Finally, I've modified message delivery to always use the jmsra jca 1.5 adapter and correspondingly removed the asf classes. thanks david jencks /** * David Jencks * Partner * Core Developers Network * http://www.coredevelopers.net **/ --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] XSLSubDeployer improvements and jca 1.5 mdb deployment
Yes indeed, many thanks. I need to retest since I made some additions since the original commit. Sorry for the delay on this, I've been having trouble connecting to cvs today. david jencks On Tuesday, June 17, 2003, at 03:05 PM, Adrian Brock wrote: Hi David, Did you forget to commit stylesheets/JMSMDBTemplate.xsl? Regards, Adrian Adrian Brock Director of Support Back Office JBoss Group, LLC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Jencks Sent: 16 June 2003 05:32 To: [EMAIL PROTECTED] Subject: [JBoss-dev] XSLSubDeployer improvements and jca 1.5 mdb deployment I've modified the deployment system to allow for multiple xml deployment descriptors. XSLSubDeployer can be configured via the Properties valued DdNameToKeyMap property to import the specified dds and store them in the DeploymentInfo under the specified key. The properties lines look like dd-name=KEY. I've also added the new DeploymentInfoURIResolverFactory which can resolve uris to documents in the current deployment info or documents in other DeploymentInfo mbeans. URIs are of the form jboss-di://deployment-info-name#key#xpath expression. The deployment-info-name and xpath-expression are optional. The DeploymentInfoDocumentURIResolver is now obsolete. I've discovered that use of two # characters in a URI is ungrammatical so the first will be changed to ! shortly. I've simplified the ejb container mbeans to remove common code to the Container class and allow deployment of MDBs with arbitrary interfaces per the ejb 2.1 spec. However, only jms MessageListener MDBs can be deployed at the moment. Deployment proceeds by constructing and deploying an ActivationSpec xmbean instance from the ejb 2.0 mdb dd. Finally, I've modified message delivery to always use the jmsra jca 1.5 adapter and correspondingly removed the asf classes. thanks david jencks /** * David Jencks * Partner * Core Developers Network * http://www.coredevelopers.net **/ --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] XSLSubDeployer improvements and jca 1.5 mdb deployment
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. 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. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, June 15, 2003 9:32 PM Subject: [JBoss-dev] XSLSubDeployer improvements and jca 1.5 mdb deployment I've modified the deployment system to allow for multiple xml deployment descriptors. XSLSubDeployer can be configured via the Properties valued DdNameToKeyMap property to import the specified dds and store them in the DeploymentInfo under the specified key. The properties lines look like dd-name=KEY. I've also added the new DeploymentInfoURIResolverFactory which can resolve uris to documents in the current deployment info or documents in other DeploymentInfo mbeans. URIs are of the form jboss-di://deployment-info-name#key#xpath expression. The deployment-info-name and xpath-expression are optional. The DeploymentInfoDocumentURIResolver is now obsolete. I've discovered that use of two # characters in a URI is ungrammatical so the first will be changed to ! shortly. I've simplified the ejb container mbeans to remove common code to the Container class and allow deployment of MDBs with arbitrary interfaces per the ejb 2.1 spec. However, only jms MessageListener MDBs can be deployed at the moment. Deployment proceeds by constructing and deploying an ActivationSpec xmbean instance from the ejb 2.0 mdb dd. Finally, I've modified message delivery to always use the jmsra jca 1.5 adapter and correspondingly removed the asf classes. thanks david jencks /** * David Jencks * Partner * Core Developers Network * http://www.coredevelopers.net **/ --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] XSLSubDeployer improvements and jca 1.5 mdb deployment
On Monday, June 16, 2003, at 01:53 PM, Scott M Stark wrote: This is not consistent with the move to extract the metadata parsing from the current deployers into filters or interceptors associated with the deployers. The key issue is to support transformation of multiple versions of the various descriptors into metadata used by the current deployer. Please explain your point of view. The XSLSubdeployer IS an interceptor. This change is in the direction of allowing a single chain of subdeployers that can deploy anything. Why would we want to preserve the current ejb metadata classes? Converting the XSLSubDeployer into a filter for the different transformations that need to be supported is also something that make more sense than leaving this as a deployer. We also need the ability for multiple deployers to operation on a given deployment if we do not already. As noted, my changes to XSLSubDeployer supply a considerable amount of this functionality. They are not proposed as a complete solution, but they do allow deployment of mdbs in accordance with the jca 1.5 spec. david jencks /** * David Jencks * Partner * Core Developers Network * http://www.coredevelopers.net **/ Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, June 15, 2003 9:32 PM Subject: [JBoss-dev] XSLSubDeployer improvements and jca 1.5 mdb deployment I've modified the deployment system to allow for multiple xml deployment descriptors. XSLSubDeployer can be configured via the Properties valued DdNameToKeyMap property to import the specified dds and store them in the DeploymentInfo under the specified key. The properties lines look like dd-name=KEY. I've also added the new DeploymentInfoURIResolverFactory which can resolve uris to documents in the current deployment info or documents in other DeploymentInfo mbeans. URIs are of the form jboss-di://deployment-info-name#key#xpath expression. The deployment-info-name and xpath-expression are optional. The DeploymentInfoDocumentURIResolver is now obsolete. I've discovered that use of two # characters in a URI is ungrammatical so the first will be changed to ! shortly. I've simplified the ejb container mbeans to remove common code to the Container class and allow deployment of MDBs with arbitrary interfaces per the ejb 2.1 spec. However, only jms MessageListener MDBs can be deployed at the moment. Deployment proceeds by constructing and deploying an ActivationSpec xmbean instance from the ejb 2.0 mdb dd. Finally, I've modified message delivery to always use the jmsra jca 1.5 adapter and correspondingly removed the asf classes. thanks david jencks /** * David Jencks * Partner * Core Developers Network * http://www.coredevelopers.net **/ --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] XSLSubDeployer improvements and jca 1.5 mdb deployment
The XSLSubdeployer is acting as an interceptor and a deployer. The transformation activity needs to be factored out from the subdeployer behavior. It makes no sense to add subdeployers that really do not deploy anything simply to achive the side effect of an interceptor. Futher, the deployers need to stop dealing with the descriptor xml document parsing and instead operate on the descriptor metadata object model. This allows for a 4.0 deployer to deal with previous version deployment decriptors as the transformation from 3.0, 3.2, 4.0 deployment descriptors to the current deployment metadata is done outside of the deployer by a filter. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, June 16, 2003 5:48 PM Subject: 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 **/ --- 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
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David Jencks Sent: Monday, June 16, 2003 8:49 PM To: [EMAIL PROTECTED] Subject: 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? Why? Because everybody is very familiar with them. Why? because its simple and easy to maintain and modify. Yes, the XML parsing needs to be moved to a separate module, but the classes themselves have held up fine. I will not allow you to add anything overly complex like the mess you did with datasources. David, you have never ever built a piece of software for JBoss that was even remotely intuitive to configure. Configuration is not your strength so please STAY AWAY from it. I'm warning you. If I see an XSLT translation anywhere within EJB land I will roll it back. Guys guys! These are configuration files! We're doing something seriously wrong here if we're doing XSLT transformations and jumping through hoops just to configure a bit of metadata. The implementation of configuration needs to be simple enough so that the casual JBoss contributor can easily add his/her little configuration tweak. All you're doing by adding all these configuration abstractions is putting up barriers for new developers. 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
RE: [JBoss-dev] XSLSubDeployer improvements and jca 1.5 mdb deployment
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Scott M Stark Sent: Monday, June 16, 2003 11:35 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] XSLSubDeployer improvements and jca 1.5 mdb deployment The XSLSubdeployer is acting as an interceptor and a deployer. The transformation activity needs to be factored out from the subdeployer behavior. It makes no sense to add subdeployers that really do not deploy anything simply to achive the side effect of an interceptor. Futher, the deployers need to stop dealing with the descriptor xml document parsing and instead operate on the descriptor metadata object model. This allows for a 4.0 deployer to deal with previous version deployment decriptors as the transformation from 3.0, 3.2, 4.0 deployment descriptors to the current deployment metadata is done outside of the deployer by a filter. Not sure I like this idea. Tell me why we need to support 3.2 and 3.0 descriptors in 4.0? I'd much rather a 3.2 component crap out gracefully in 4.0 than have to maintain 3 separate configuration mechanisms. I do like the idea of having a metamodel separate from XML parsing. BUT STILL, it is quite easy to navigate the current metadata/XML marriage that now exists in current configuration. Are you sure we're actually gaining any maintainability by changing the status quo? 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
[JBoss-dev] XSLSubDeployer improvements and jca 1.5 mdb deployment
I've modified the deployment system to allow for multiple xml deployment descriptors. XSLSubDeployer can be configured via the Properties valued DdNameToKeyMap property to import the specified dds and store them in the DeploymentInfo under the specified key. The properties lines look like dd-name=KEY. I've also added the new DeploymentInfoURIResolverFactory which can resolve uris to documents in the current deployment info or documents in other DeploymentInfo mbeans. URIs are of the form jboss-di://deployment-info-name#key#xpath expression. The deployment-info-name and xpath-expression are optional. The DeploymentInfoDocumentURIResolver is now obsolete. I've discovered that use of two # characters in a URI is ungrammatical so the first will be changed to ! shortly. I've simplified the ejb container mbeans to remove common code to the Container class and allow deployment of MDBs with arbitrary interfaces per the ejb 2.1 spec. However, only jms MessageListener MDBs can be deployed at the moment. Deployment proceeds by constructing and deploying an ActivationSpec xmbean instance from the ejb 2.0 mdb dd. Finally, I've modified message delivery to always use the jmsra jca 1.5 adapter and correspondingly removed the asf classes. thanks david jencks /** * David Jencks * Partner * Core Developers Network * http://www.coredevelopers.net **/ --- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
