Re: Fwd: Re: How I plan to move forward.

Geoff Longman wrote:
> 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.
>
>   
ah! something good comes out of it already! :-)
>> 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
>
>   
Somewhere in resolution-land, you have to accept that there has to be a
'convention' for how to do things and just fail gracefully after that
[fail gracefully: verb; to indicate to user that something is amiss.
often confused with dialog box indicating "error. error. error."] ;-)
>   
>> 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!
>   
Well, I'm glad you don't understand it - because I didn't either. ;-)
[This example, while contrived, is the simplest example of an
integration issue I recently faced]

Scenario:
  In the application file, add the following line:
    <meta key="org.apache.tapestry.page-class-packages"
value="com.mycompany.tapestry.site.pages"/>

  In the .page file, set the page-specification class="PageOne".
  Create a PageOne.java file under com.mycompany.tapestry.site.pages.
(valid page file)

Deploy:
  Compile PageOne.java into its class and create a jar file -
mycompany-site.jar. Add this jar file to WEB-INF/lib

Result:

Could not load class PageOne from WebappClassLoader
  delegate: false
  repositories:
    /WEB-INF/classes/
----------&gt; Parent Classloader:
org.apache.catalina.loader.StandardClassLoader@1629e71 : PageOne



To fix:  Change the page-specification class from "PageOne" to
"com.mycompany.tapestry.site.pages.PageOne". PageOne now loads correctly.

Odd? yes. True. unfortunately. Unless something's gone awry in my
environments. To note: it's (obviously - with the inclusion of the
org.apache.catalina package) under Tomcat. Haven't tried Resin or Jetty.
(as he looks to his Jetty install....)


-------------------------------------------------------
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&kid=103432&bid=230486&dat=121642