Fwd: Re: How I plan to move forward.

rats

---------- Forwarded message ----------
From: Geoff Longman <[email protected]>
Date: Feb 19, 2006 11:41 PM
Subject: Re: [Spindle-developer] Re: How I plan to move forward.
To: [email protected]


> > These are cases exclusions won't help solve.
> >
> > Perhaps relax the "namespaces are never to overlap" rule into
> > "namespaces may never be colocated" (bad wording for sure).
> >
> > Hmm, pondering...
> >
> It may seem like bad wording, but I like it. The case of .application +
> .library to me has always been contentious at best (may as well just
> have one .txt file that processes everything). As for
> /com/mystuff/*.library - I think this would indeed be a corner case. As
> users find out all too often that they live in corners, I know. But
> disallowing colocation should be a definite step in the right direction.

I think so too. The wheels are turning in my head on how to implement
this and, as an almost side effect, handle cases where libraries that
are missed in the current plugin are now caught and handled correctly.

>
> As a side question... is there any differentiation between the following:
> library1.jar:/com/mystuff/foo.library
> library2.jar:/com/mystuff/bar.library
> WEB-INF/classes/com/mystuff/foo2.library

Well, Tapestry uses ClasspathResource's for all classpath things
(there is no special Resources for jars vs WEB-INF/classes) and they
use the classloader to fetch the contents of these locations so I
would say that there is no differentiation - they would all be
considered to be 'colocated'.

As a side note something like this added to your list:

library3.jar:/com/mystuff/foo.library

would either be seen (and hide foo.library in library1.jar) or not
seen (be hidden by foo.library in library1.jar) depending on the order
the jars occur in the classpath used by the classloader.

I would expect that servlet containers would put /WEB-INF/classes
ahead of any jars in /WEB-INF/lib so in the following case:

library4.jar:com/mystuff/foo2.library

would always be 'hidden' by:

WEB-INF/classes/com/mystuff/foo2.library


>
> The reason I ask is that currently Tapestry itself distinguishes between
> jar'ed resources and classes on the classpath (for page-spec packages at
> least).

I don't understand the above statement. I think you'll find that
resources/classes are 'found' in the classpath based on the
classpath'y ordering of things.

Although, if you have a concrete example to share I'm keen to see it!

>I know this would be another can of worms - but still more in
> the 'corner-case' scenarios than anything [my work with Tapestry has
> been deeply rooted in an extreme corner-case environment, so don't think
> I discount corner-cases as insignificant]

Geoff


--
The Spindle guy.          http://spindle.sf.net
Get help with Spindle:
http://lists.sourceforge.net/mailman/listinfo/spindle-user
Blog:                     http://jroller.com/page/glongman
Feature Updates:          http://spindle.sf.net/updates


--
The Spindle guy.          http://spindle.sf.net
Get help with Spindle:   
http://lists.sourceforge.net/mailman/listinfo/spindle-user
Blog:                     http://jroller.com/page/glongman
Feature Updates:          http://spindle.sf.net/updates


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642