A common problem I see again and again is when people miss-spell the filenames of XML artefacts that live in the META-INF and WEB-INF directories of a JEE archive. I also see people (myself included) putting these artefacts in the wrong location, For example, putting the beans.xml file in the META-INF of a .war when it belongs in the WEB-INF. This can cause a big headache as it looks like you have created the right artifact, but it is not taking effect. It would be great if we could detect this type of thing and warn the developer at deploy time. There seems to be a move towards using marker files (beans.xml, faces-config.xml) to enable technologies, so this issue could become more prevalent. One solution, I was thinking about, is to check the schema type of all the XML files in the META-INF and WEB-INF directories. For each schema that we recognize (http://java.sun.com/xml/ns/persistence for example), we check that it's file name is correct and it is in a location where it will be processed. Does this sound like a sensible thing for us to do? Paul. -- Paul Robinson Web service transactions lead paul.robinson(a)redhat.com JBoss, a Division of Red Hat Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham (USA), Brendan Lane (Ireland), Matt Parson (USA), Charlie Peters (USA) _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

From: "Jason T. Greene" <jason.greene(a)redhat.com&gt; To: jboss-as7-dev(a)lists.jboss.org Sent: Friday, February 24, 2012 8:57:34 AM Subject: Re: [jboss-as7-dev] Detecting deployment location errors for xml files using a JEE schema On 2/24/12 8:36 AM, Paul Robinson wrote: > A common problem I see again and again is when people miss-spell > the > filenames of XML artefacts that live in the META-INF and WEB-INF > directories of a JEE archive. I also see people (myself included) > putting these artefacts in the wrong location, For example, putting > the > beans.xml file in the META-INF of a .war when it belongs in the > WEB-INF. > This can cause a big headache as it looks like you have created the > right artifact, but it is not taking effect. It would be great if > we > could detect this type of thing and warn the developer at deploy > time. > There seems to be a move towards using marker files (beans.xml, > faces-config.xml) to enable technologies, so this issue could > become > more prevalent. > > One solution, I was thinking about, is to check the schema type of > all > the XML files in the META-INF and WEB-INF directories. For each > schema > that we recognize (http://java.sun.com/xml/ns/persistence for > example), > we check that it's file name is correct and it is in a location > where it > will be processed. > > Does this sound like a sensible thing for us to do? I think the idea is good, but looking at the content of all xml files would slow down deployment time, especially for large complex nested deployments. So if we did this as part of deployment it would be more efficient to do it based on file name matching. Common misspellings could be checked for using a static map. So I would still prefer extensive checking like this to be an optional deployment tool/maven task. If however someone comes up with a patch which is able to demonstrate no significant delay, we would certain reconsider. -- Jason T. Greene JBoss AS Lead / EAP Platform Architect JBoss, a division of Red Hat _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

alternatively you could have an explicit "sanity-check" operation that you could run on a deployment "after-the-fact" to report issues it finds. Then have a setting to say if you want this on all deployments or not, but by default run it in case deployments fail. This would make it easily accessible + not delay the deployment in the "working case" and only pay the price if it fails. Of course you can still have deployments that doesn't fail but have sanity errors but this is why you should be able to run this after deployment occurred. /max On Feb 24, 2012, at 5:48 PM, Andrig Miller wrote: > Perhaps there could be a "DEBUG" option on the deployers that would do this, and and it could be turned on and off? > > Andy > > ----- Original Message ----- >> From: "Jason T. Greene" <jason.greene(a)redhat.com&gt; >> To: jboss-as7-dev(a)lists.jboss.org >> Sent: Friday, February 24, 2012 8:57:34 AM >> Subject: Re: [jboss-as7-dev] Detecting deployment location errors for xml files using a JEE schema >> >> On 2/24/12 8:36 AM, Paul Robinson wrote: >>> A common problem I see again and again is when people miss-spell >>> the >>> filenames of XML artefacts that live in the META-INF and WEB-INF >>> directories of a JEE archive. I also see people (myself included) >>> putting these artefacts in the wrong location, For example, putting >>> the >>> beans.xml file in the META-INF of a .war when it belongs in the >>> WEB-INF. >>> This can cause a big headache as it looks like you have created the >>> right artifact, but it is not taking effect. It would be great if >>> we >>> could detect this type of thing and warn the developer at deploy >>> time. >>> There seems to be a move towards using marker files (beans.xml, >>> faces-config.xml) to enable technologies, so this issue could >>> become >>> more prevalent. >>> >>> One solution, I was thinking about, is to check the schema type of >>> all >>> the XML files in the META-INF and WEB-INF directories. For each >>> schema >>> that we recognize (http://java.sun.com/xml/ns/persistence for >>> example), >>> we check that it's file name is correct and it is in a location >>> where it >>> will be processed. >>> >>> Does this sound like a sensible thing for us to do? >> >> I think the idea is good, but looking at the content of all xml files >> would slow down deployment time, especially for large complex nested >> deployments. So if we did this as part of deployment it would be more >> efficient to do it based on file name matching. Common misspellings >> could be checked for using a static map. So I would still prefer >> extensive checking like this to be an optional deployment tool/maven >> task. If however someone comes up with a patch which is able to >> demonstrate no significant delay, we would certain reconsider. >> >> -- >> Jason T. Greene >> JBoss AS Lead / EAP Platform Architect >> JBoss, a division of Red Hat >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >> > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

Perhaps there could be a "DEBUG" option on the deployers that would do this, and and it could be turned on and off?

Andy ----- Original Message ----- > From: "Jason T. Greene&quot;&lt;jason.greene(a)redhat.com&gt; > To: jboss-as7-dev(a)lists.jboss.org > Sent: Friday, February 24, 2012 8:57:34 AM > Subject: Re: [jboss-as7-dev] Detecting deployment location errors for xml files using a JEE schema > > On 2/24/12 8:36 AM, Paul Robinson wrote: >> A common problem I see again and again is when people miss-spell >> the >> filenames of XML artefacts that live in the META-INF and WEB-INF >> directories of a JEE archive. I also see people (myself included) >> putting these artefacts in the wrong location, For example, putting >> the >> beans.xml file in the META-INF of a .war when it belongs in the >> WEB-INF. >> This can cause a big headache as it looks like you have created the >> right artifact, but it is not taking effect. It would be great if >> we >> could detect this type of thing and warn the developer at deploy >> time. >> There seems to be a move towards using marker files (beans.xml, >> faces-config.xml) to enable technologies, so this issue could >> become >> more prevalent. >> >> One solution, I was thinking about, is to check the schema type of >> all >> the XML files in the META-INF and WEB-INF directories. For each >> schema >> that we recognize (http://java.sun.com/xml/ns/persistence for >> example), >> we check that it's file name is correct and it is in a location >> where it >> will be processed. >> >> Does this sound like a sensible thing for us to do? > I think the idea is good, but looking at the content of all xml files > would slow down deployment time, especially for large complex nested > deployments. So if we did this as part of deployment it would be more > efficient to do it based on file name matching. Common misspellings > could be checked for using a static map. So I would still prefer > extensive checking like this to be an optional deployment tool/maven > task. If however someone comes up with a patch which is able to > demonstrate no significant delay, we would certain reconsider. > > -- > Jason T. Greene > JBoss AS Lead / EAP Platform Architect > JBoss, a division of Red Hat > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev > _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

On 2/24/12 8:36 AM, Paul Robinson wrote: > A common problem I see again and again is when people miss-spell the > filenames of XML artefacts that live in the META-INF and WEB-INF > directories of a JEE archive. I also see people (myself included) > putting these artefacts in the wrong location, For example, putting the > beans.xml file in the META-INF of a .war when it belongs in the WEB-INF. > This can cause a big headache as it looks like you have created the > right artifact, but it is not taking effect. It would be great if we > could detect this type of thing and warn the developer at deploy time. > There seems to be a move towards using marker files (beans.xml, > faces-config.xml) to enable technologies, so this issue could become > more prevalent. > > One solution, I was thinking about, is to check the schema type of all > the XML files in the META-INF and WEB-INF directories. For each schema > that we recognize (http://java.sun.com/xml/ns/persistence for example), > we check that it's file name is correct and it is in a location where it > will be processed. > > Does this sound like a sensible thing for us to do? I think the idea is good, but looking at the content of all xml files would slow down deployment time, especially for large complex nested deployments. So if we did this as part of deployment it would be more efficient to do it based on file name matching. Common misspellings could be checked for using a static map. So I would still prefer extensive checking like this to be an optional deployment tool/maven task. If however someone comes up with a patch which is able to demonstrate no significant delay, we would certain reconsider.

A common problem I see again and again is when people miss-spell the filenames of XML artefacts that live in the META-INF and WEB-INF directories of a JEE archive. I also see people (myself included) putting these artefacts in the wrong location, For example, putting the beans.xml file in the META-INF of a .war when it belongs in the WEB-INF. This can cause a big headache as it looks like you have created the right artifact, but it is not taking effect. It would be great if we could detect this type of thing and warn the developer at deploy time. There seems to be a move towards using marker files (beans.xml, faces-config.xml) to enable technologies, so this issue could become more prevalent. One solution, I was thinking about, is to check the schema type of all the XML files in the META-INF and WEB-INF directories. For each schema that we recognize (http://java.sun.com/xml/ns/persistence for example), we check that it's file name is correct and it is in a location where it will be processed. Does this sound like a sensible thing for us to do? Paul.