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

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
>