Re: [jboss-as7-dev] Consolidated list of non-Java EE JPA and native Hibernate issues
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.