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

I was wrong, sorry. Acording to the docs your example should work. I didn't
know that, always learning :o)

On 20/02/06, Hugo Palma <[email protected]> wrote:
>
> 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
> >
>
>