JBAS-7834 XMLs contained by archives are parsed aggressively by deployers, resulting in unexpected errors

[marius.bogoevici]

Moving https://jira.jboss.org/jira/browse/JBAS-7834 here

What I submitted was:

<quote>

Take a working application (like a very basic war) and add a file ending in -hibernate.xml (e.g. /WEB-INF/application-hibernate.xml) which references a schema which is unknown to the Hibernate Deployer (or no schema).

A simple file containing this:

<broken/>

would do. 

From this point on, the application will fail deploying consistently. Unfortunately, application-hibernate.xml is not a reserved file name under JavaEE, so a valid application may contain such files and fail to deploy. In such cases, the application server should be more lenient and ignore those files.

Note 1: the problem may appear for other suffixes.

Note 2: the problem has been sporadically noticed in the Spring world, but it's not necessarily a Spring-related issue (heavy usage of XML in Spring may trigger the problem more consistently).

</quote>

Ales' answer was:

<quote>

Can you move this to AS dev forum first for discussion?

As I cannot see this as very useful, either
* simply rename your file
* change app. server's matching suffix
* remove the deployer
 
All are trivial to get right.
But I'm opened to discussion / suggestions.
</quote>

Message was edited by: Marius Bogoevici - formatting

[marius.bogoevici]

Ales, I am aware of the workarounds, but the main reason why I am pointing this out is that we're talking about perfectly legitimate applications, doing things which are not specifically prohibited under Java EE, yet failing to deploy properly.

All I am saying is, that for bits which are not specifically indicated by Java EE (like for example META-INF/persistence.xml), we could ignore xml files that cannot be parsed correctly, as if they wouldn't be part of the deployment. So if I have a non-Java EE deployer, and I happen to have a legacy application that would happen to match it, that would be a problem.

All the things you suggested are very easy to do, but the simple requirement of tweaking the application or the application server, although fairly easy to do during development, may not fare well within a larger application development environment.

So if we aren't willing to fix this, then we should at least document the list of reserved file names shipped with the JBoss AS.

[alesj]

All I am saying is, that for bits which are not specifically indicated by Java EE (like for example META-INF/persistence.xml), we could ignore xml files that cannot be parsed correctly, as if they wouldn't be part of the deployment. So if I have a non-Java EE deployer, and I happen to have a legacy application that would happen to match it, that would be a problem.

All the things you suggested are very easy to do, but the simple requirement of tweaking the application or the application server, although fairly easy to do during development, may not fare well within a larger application development environment.

So if we aren't willing to fix this, then we should at least document the list of reserved file names shipped with the JBoss AS.

OK, I see your point.

I'll add a flag to our parsing deployers, which will indicate that the file we're parsing can fail -- e.g. invalid match.

Otoh, we already have a mechanism for ignoring files at parsing -- see AbstractParsingDeployerWithOutput::ignoreName().

Do you have any preferences on how to enable this for such users?