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

The docs appear to be ok. I'm looking at:

http://jakarta.apache.org/tapestry/UsersGuide/page-class.html

what is missing is a statement that once an entry in the search chain
matches, search stops.

Geoff

On 2/20/06, Hugo Palma <[email protected]> wrote:
> My first impression was correct after all. I got fooled by the docs.
>
> Cheers
>
> Hugo
>
>
> On 20/02/06, Geoff Longman < [email protected]> wrote:
> > I'm looking at the T4 code...The PageLoader uses the PageClassProvider
> > to find a String name for the page class.
> >
> > It's a HiveMind service that, in the default config...
> >
> > looks for the class attribute on <page-specification>
> > does the search thing
> > uses the namespace default (defined by a meta )
> > uses the Global default (BasePage usually)
> >
> > if one matches the search stops.
> >
> > Once the String name of the class has been found PageLoader tries to
> > instantiate it. If not found - throw ApplicationRuntimeException. No
> > further attempt is made to find the class.
> >
> > So, if the class attribute of <page-specification> is set, it must be an
> fqn.
> >
> > Perhaps the docs are unclear but this is what the code does.
> >
> > Geoff
> >
> >
> >
> > On 2/20/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
> > > >
> > >
> > >
> >
> >
> > --
> > 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