Mapping web resources over VDF

[alesj]

WRT:
- http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4203370#4203370
- http://www.jboss.com/index.html?module=bb&op=viewtopic&t=149197

How hard would it be to 'move'/impl JBossWeb's TLD lookup based on MC's VDF?

My use case for JBossPortal (JBP) would be:
1) recognize that deployment is JBP app
2) add JBP's custom TLD to VFSDeploymentUnit's metadata locations

e.g.

VirtualFile customJbpTLDs = VFS.getRoot(".../jboss-portal/config/tlds");
unit.appendMetaDataLocation(customJbpTLDs);

3) JBossWeb would understand VDF (VFSDeploymentUnit - VDU)
and do a tld lookup based on VDU's metadata locations

This would mean if we run in an environment that uses VDF
we should first try to look for metadata via VDF
only then fall back to plain resources lookup.

This way the services that use VDF won't have to introduce
hacks to add custom metadata - like JBP does it currently.

btw: where exactly does .tld file lookup happen?

[alesj]

Normally, the web tier embedded in AS uses VFS for almost everything
already (it has a DirContext-over-VFS implementation), but indeed TLD
may use some work. It should be pluggable for Catalina (it only uses it
to lookup for listeners), but for Jasper it's harder. I sort of hoped
nobody would notice ... So I suppose some review is needed.

[alesj]

Normally, the web tier embedded in AS uses VFS for almost everything
already (it has a DirContext-over-VFS implementation),

As it seems, direct VFS is not enough,
we need whole VDF, with its mutable VFSDeploymentUnit (VDU).

Like my code suggests, one would add an 'external' metadata location,
containing custom resources (in JBP's case their custom .tld),
and once web tier would do a lookup for those resources,
it would go over VDU's metadata locations, not really caring where they come from.

[alesj]

it has a DirContext-over-VFS implementation

I'm having problems locating the usage of VFSDirContext.
It used to be in TomcatDeployment, but it's not there anymore.

[alesj]

Ok, I've had a look and I remember the story a bit better now. The
bottom line is that it's not going to happen (running on VFS works fine,
but makes certain legacy Servlet API features not work - like the
getRealPath stuff).

So the solution is to (eventually) provide some configuration in Jasper
to allow plugging in the component that handles TLDs.

And that is really the best I can offer.

[alesj]

"alesj" wrote:

At least I wouldn't limit myself to TLDs ... if that's possible.

All "standard" descriptors and annotations are already given by AS.
context.xml files are then read through the VFS in JBossContextConfig.
The only thing missing is really TLDs, parsed using TldLocationsCache
and TagLibraryInfoImpl in Jasper, which is not pluggable right now.

It is a two step process:
1) scan to associate the requested taglib uri with the location of its
TLD
2) parse the actual TLD file

"alesj" wrote:

afaik they are eager to get things working cleanly/nicely on the new VDF.

Hence the mutable VFSDeploymentUnit.

That's what is used: WebApplication.getDeploymentUnit.getFile

But redoing TLD processing is not trivial. I think in theory since they
are standard EE metadata, then the parsing should be in
JBossWebMetaData, and Jasper should not have to do any TLD scanning and
parsing like it does right now.

[alesj]

"alesj" wrote:

then the parsing should be in
JBossWebMetaData, and Jasper should not have to do any TLD scanning and parsing like it does right now.

Exactly!
Couldn't agree more.

How fast can we change this? :-)

Not very fast.

For starters, TLDs are located in a variety of funny locations, which
usually needs caching since usually people also want to be able to put
some in shared JARs, etc :(
Then Jasper components need to be pluggable and have a new impl.
And then test and fix problems.

To be honest, if you are in a hurry, there is no way you can rely on
this.