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

Maybe i'm not seeing your example correctly, but i don't think that that
works with the page class in WEB-INF/class either.
AFAIK when you specify the class attribute in the page spec it has to be the
fully qualified name of the class. I did a quick test and it never worked
for me when i don't use the fqn of the class.

Cheers

Hugo

On 20/02/06, CrossHelix <[email protected]> wrote:
>
>
>
> 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
> _______________________________________________
> Spindle-developer mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/spindle-developer
>