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

I know, but it was the part that says:

"Also, for this search, the page name is converted into a partial class
name. For pages inside folders, the folder names are part of the package
name, so page name admin/EditUser will be become admin.EditUser.

So, if the prefix list is org.example.pages, then Tapestry will search for
org.example.pages.admin.EditUser, then admin.EditUser (that is, in the
default package)."
that got me thinking that giving a partial name in the spec was actually
valid. Now that read this part again, it really doesn't say, i just thought
it did from a quick read. The docs aren't wrong, i guess it's just the way
that it's written that might lead to error.



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