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

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


-------------------------------------------------------
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