This seems to give us a good compromise. From the users point of view it
would look the same as if it was done as part of deployment, but it
doesn't affect the deployment time.
As Andy said, it would probably still make sense to allow this to be
turned off. There may be a number of false positives displayed which the
user will have to hunt through when searching for the outcome of the
deployment in the log.
Paul.
On 26/02/12 08:36, Max Rydahl Andersen wrote:
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>
>> 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
--
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)