On Fri, 2008-08-01 at 09:22 -0500, David M. Lloyd wrote:
On 07/29/2008 07:40 AM, Adrian Brock wrote:
AbstractParsingDeployerWithOutput is the "highest" class with a suffix
property on it. Searching for uses reveals that there really is no one
place where the matching logic is implemented.
That class provides the standard config options.
AbstractVFSParsingDeployer's isDeployable(VirtualFile) method
suffix and just returns a boolean, so presumably there's something that
scans through, looking for the first one that matches...
That class + its children implements the option(s),
since only the VFS provides the ability to "list a URL", e.g.
match all files in META-INF that end with the suffix.
Looks like the logic is actually in FileStructure... though it
how I expected. There's a checkFileMatchers() method that returns true if
*some* file matcher matches, though it doesn't say which one. Find usages
on that method reveals a dead end. I must be barking up the wrong tree?
Yep, its not even a tree you are barking at. :-)
The FileStructure is not doing parsing or META-INF searching.
It is looking for candidate subdeployments.
e.g. -service.xml files in the root of a jar.
We could just allow FileMatchers to be injected
into the parsing deployers (as Ales suggested to me).
That way somebody could change the matching rules to whatever they want.
But it smells to me like YAGNI. :-)
But configuring a FileMatcher for every parser
just to match a suffix or whole file name is overkill
for these simple use cases.
So if we were going to do it, the old simple rules should still be there
with the more complicated injectable FileMatcher resevered for
Ah well, I'm defeated for now. Too much other stuff to do. If
wants to tackle this, I think it's worth doing, but beyond my capabilities
for the time being.
jboss-development mailing list
JBoss, a division of Red Hat