[jboss-as7-dev] Consolidated list of non-Java EE JPA and native Hibernate issues

[Marius Bogoevici]

On 08/30/2011 11:41 AM, Jason T. Greene wrote:
> On 8/30/11 10:25 AM, Marius Bogoevici wrote:
>> On 08/30/2011 10:52 AM, Scott Marlow wrote:
>>> Is anyone working on jboss-ignore.txt for AS7.x?  I'm still wondering
>>> if we should have a way to tell JPA to ignore a deployment.
>> https://issues.jboss.org/browse/AS7-1128
>>
>> I started prototyping something a while ago then it couldn't make it to
>> 7.0 so I slacked it off. Need to bring back though - I can get back to
>> this next week, unless anyone wants to take over beforehand.
>>
>> One issue that I have encountered for a generic implementation was that
>> deployment processors read files directly from VFS, so we cannot easily
>> incorporate the information from jboss-ignore.txt in the deployment
>> process (as it was the case with the MC-based deployers, where Ales
>> added the jboss-ignore.txt processing into one of the superclasses).
>>
>> So, I'm wondering what is the best way of handling this:
>>
>> a) Adding an intermediate DeploymentResources object that sits on top of
>> VFS and incorporates the filtering information from jboss-ignore.txt .
>> Deployment processors would use DeploymentResources to get a filtered
>> view of the deployment resources instead of using VFS directly.
>>
>> b) Using jboss-deployment-structure.xml for dedicated deployment
>> instructions (<ignore-jpa/>)
>>
>> c)?
>>
>> My preferred alternative would be a), perhaps incorporating filtering
>> rules in jboss-deployment-structure.xml.
>>
>> Thoughts?
> I think we first need to come up with the list of use cases for what we
> want to be disabled. There is a large potential for this feature to
> break things or not work as intended. For example, if you exclude
> web.xml you aren't guaranteed to disable servlets.
Surely, you would need to know what you disabled.

The one use case that I can think of is to tell the server to ignore 
persistence.xml (or suppress PU deployment). There may be some other 
cases, like legacy projects which happen to have a beans.xml file in the 
wrong place (but aren't necessarily CDI deployments). It could become 
useful if future versions of Java EE start adding configuration files 
which are likely to break current deployments.

As I said, I believe that there is always room to create specific 
instructions for specific types of deployments instead of blocking out 
files outright - the problem is that each type of 'disable xyz' action 
would need to be implemented separately.
>
> It also causes a problem with annotation scanning. If someone bundles an
> index that contains entries to classes which are then filtered by this
> ignore feature it will either blow up or not do what they thought they
> intended.
Not sure if that is an issue. I never had classloader exclusion in mind 
(and wouldn't that be part of resource filtering?). The intent simply 
was to leave the files on the classpath (if any part of the deployment 
wishes to use them) but tell the deployers not to use them.