Spring DM (web.extender) creates a compound ClassLoader from all
imported bundles/libraries and set this loader as context class loader.
So it should see these classes.

I don't see much value of these annotations that Doug proposes (actually
this idea was already discussed before). What's better than mounting the
pages in MyApplication.java? That's the purpose of this class - to
configure my application.
This is my personal opinion.

On Sun, 2008-05-04 at 09:47 -0700, Doug Donohoe wrote:
> I'm using:
> 
> http://static.springframework.org/spring/docs/2.5.x/api/org/springframework/core/io/support/PathMatchingResourcePatternResolver.html
> 
> I'm not sure if it will discover items added through OSGI.   Having never
> used OSGI, I'd need someone to test that for me or provide me with a sample.
> 
> -Doug
> 
> 
> Johan Compagner wrote:
> > 
> > about that class path scanning..
> > is spring taken into account that you can have wicket components packages
> > and added throught OSGI?
> > What class loaders does it use?
> > 
> > johan
> > 
> > 
> > On Sun, May 4, 2008 at 3:57 PM, Doug Donohoe <[EMAIL PROTECTED]> wrote:
> > 
> >>
> >> Hi Johan,
> >>
> >> Yes, I came across that issue late yesterday - a small oversight :-). 
> >> I'm
> >> still
> >> getting to know the framework.  However, all is not lost.  The bulk
> >> of my work was getting the annotations working properly.  It  will
> >> be easy to go back my original idea of classpath scanning via some
> >> Spring utility classes.  They are quite fast (in answer to the question
> >> about speed).  You can also limit the scan to a portion of the classpath
> >> e.g., "classpath*:com.donohoedigital".
> >>
> >> This probably means it will have to go into a wicket stuff project
> >> at least at the start.
> >>
> >> I'm working the switch this morning.  It shouldn't take too long as I
> >> already have the code written to class-path scan for an Annotated
> >> class that I used in another part of my code base.
> >>
> >> -Doug
> >>
> >>
> >>
> >> Johan Compagner wrote:
> >> >
> >> > So you create mounts on the fly when a setResponsePage(Class) is set?
> >> > How do you do it the other way around? If the mount didnt happen yet
> >> > by a setResponsePage call but there is a url coming in?? This can
> >> > happen just fine  if you had to restart the server or something.
> >> >
> >> > On 5/4/08, Doug Donohoe <[EMAIL PROTECTED]> wrote:
> >> >>
> >> >> Yes, you can do that.  But I prefer not to have to modify Application
> >> >> when I
> >> >> add a new page.  With an annotation-based approach, I define a page,
> >> >> annotate it and then I'm done.
> >> >>
> >> >> Really, this is just a philosophical difference.  Rather than argue
> >> which
> >> >> is
> >> >> better, we could offer both. Annotation usage is a matter of
> >> preference.
> >> >> Some people will want to use it; others not.  Adding mounts in the
> >> >> application init() method may make more sense for some applications
> >> than
> >> >> others.  In my application, I think using annotations is much simpler.
> >> >>
> >> >> The code I have is working and is pretty non-invasive change to
> >> >> WebRequestCodingStrategy (see below for how I did it via subclassing).
> >>  I
> >> >> need to get Wicket building in my environment so I can figure out
> >> where
> >> >> to
> >> >> put the annotation classes so I can submit a patch.
> >> >>
> >> >> -Doug
> >> >>
> >> >> public class AnnotationAwareWebRequestCodingStrategy extends
> >> >> WebRequestCodingStrategy
> >> >> {
> >> >>     @Override
> >> >>     protected IRequestTargetUrlCodingStrategy
> >> >> getMountEncoder(IRequestTarget
> >> >> requestTarget)
> >> >>     {
> >> >>         IRequestTargetUrlCodingStrategy strategy =
> >> >> super.getMountEncoder(requestTarget);
> >> >>
> >> >>         // if no strategy found, see if there is one we can create via
> >> >> annotations
> >> >>         if (strategy == null)
> >> >>         {
> >> >>             strategy = getAnnotatedMountEncoder(requestTarget);
> >> >>             if (strategy != null)
> >> >>             {
> >> >>                 mount(strategy);
> >> >>             }
> >> >>         }
> >> >>         return strategy;
> >> >>     }
> >> >>
> >> >>     protected IRequestTargetUrlCodingStrategy
> >> >> getAnnotatedMountEncoder(IRequestTarget requestTarget)
> >> >>     {
> >> >>         IRequestTargetUrlCodingStrategy strategy = null;
> >> >>
> >> >>         // If this is a bookmarkable page reqeuest, see if it has a
> >> mount
> >> >> annotation
> >> >>         if (requestTarget instanceof IBookmarkablePageRequestTarget)
> >> >>      {
> >> >>             // Look for @MountPath annotation on the page class
> >> >>             IBookmarkablePageRequestTarget target =
> >> >> (IBookmarkablePageRequestTarget)requestTarget;
> >> >>             Class<? extends Page> pageClass = target.getPageClass();
> >> //
> >> >> FIX:
> >> >> this may change in Wicket 1.4
> >> >>             strategy = getAnnotatedMountEncoder(pageClass);
> >> >>         }
> >> >>         return strategy;
> >> >>     }
> >> >>
> >> >>     protected IRequestTargetUrlCodingStrategy
> >> >> getAnnotatedMountEncoder(Class<? extends Page> pageClass)
> >> >>     {
> >> >>         // ... meat of the code here ...
> >> >>     }
> >> >>
> >> >>
> >> >> igor.vaynberg wrote:
> >> >> >
> >> >> > i prefer a simple factory method on pages that construct
> >> >> > pageparameters or even an entire bookmarkable page link...
> >> >> >
> >> >> > PageParameters params=Leaderboard.newPageParameters(someType,
> >> >> someDays);
> >> >> > add(new BookmarkablePageLink("id", Leaderboard.class, params));
> >> >> >
> >> >> > or just
> >> >> >
> >> >> > add(Leaderboard.newBookmarkableLink("id", someType, someDays));
> >> >> >
> >> >> > encapsulation without all the overhead of annots, etc
> >> >> >
> >> >> > -igor
> >> >> >
> >> >> >
> >> >> > On Sat, May 3, 2008 at 2:25 PM, Doug Donohoe <[EMAIL PROTECTED]>
> >> wrote:
> >> >> >>
> >> >> >>  One thing that is valuable is encapsulation.  For example, take my
> >> >> >>  Leaderboard class which has two main inputs via PageParameters:
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>     static final String PARAM_TYPE = "type";
> >> >> >>     static final String PARAM_DAYS = "days";
> >> >> >>
> >> >> >>  Now, using the current metaphor, I when I want to mount using a
> >> >> >> MixedParam
> >> >> >>  strategy, I have to (a) expose these as public and (b) then add
> >> code
> >> >> in
> >> >> >> my
> >> >> >>  init() method like:
> >> >> >>
> >> >> >>     mount(new MixedParamUrlCodingStrategy("leaderboard",
> >> >> >> Leaderboard.class,
> >> >> >>               new String { Leaderboard.PARAM_TYPE,
> >> >> >> Leaderboard.PARAM_DAYS});
> >> >> >>
> >> >> >>  I'm exposing information I don't really want to.  Instead, why I'm
> >> >> doing
> >> >> >> now
> >> >> >>  is:
> >> >> >>
> >> >> >>     @MountPath(path = "leaderboard")
> >> >> >>     @MountMixedParam(parameterNames = {Leaderboard.PARAM_TYPE,
> >> >> >>  Leaderboard.PARAM_DAYS})
> >> >> >>     public class Leaderboard extends WebPage { ... }
> >> >> >>
> >> >> >>  If I add or change the PARAMS, I only have to change Leaderboard -
> >> it
> >> >> >>  controls how it is mounted rather than up at the Application
> >> level.
> >> >> >>
> >> >> >>  If somebody else wants to use this page and change the mount
> >> point,
> >> >> they
> >> >> >> can
> >> >> >>  subclass:
> >> >> >>
> >> >> >>     @MountPath(path = "my/leaderboard")
> >> >> >>     public class MyLeaderboard extend Leaderboard
> >> >> >>
> >> >> >>  The @MountMixedParam annotation is inherited wherea the @MountPath
> >> is
> >> >> >> not.
> >> >> >>  I haven't tested this yet (I'll add it to my unit test), but you
> >> >> could
> >> >> >> also
> >> >> >>  specify a different mount strategy than MixedParam if you wanted
> >> to
> >> >> >> override
> >> >> >>  that.
> >> >> >>
> >> >> >>  If a class is not annotated with @MountPath, it is not mountable
> >> (via
> >> >> >>  annotations).
> >> >> >>
> >> >> >>  If you just define @MountPath and no supporting annotation, it
> >> >> defaults
> >> >> >> to
> >> >> >>  BookmarkablePage...Strategy.
> >> >> >>
> >> >> >>  Regarding multiple mounts, I could add that by making path a
> >> string
> >> >> >> array -
> >> >> >>  I wasn't sure how often that was used because the way
> >> >> >>  WebRequestCodingStrategy.getMountEncoder works is that it picks
> >> the
> >> >> >> first
> >> >> >>  one it finds (when mapping a class to a mount path).
> >> >> >>
> >> >> >>  For the curious, @MountMixedParam is defined as follows:
> >> >> >>
> >> >> >>     @Target({ ElementType.TYPE })
> >> >> >>     @Retention(RetentionPolicy.RUNTIME)
> >> >> >>     @MountDefinition(strategyClass =
> >> >> MixedParamUrlCodingStrategy.class,
> >> >> >>  argOrder = {"pageMapName", "parameterNames"})
> >> >> >>     @Inherited
> >> >> >>     @Documented
> >> >> >>     public @interface MountFixedMixedParam
> >> >> >>     {
> >> >> >>         String pageMapName() default MountDefinition.NULL;
> >> >> >>
> >> >> >>         String[] parameterNames();
> >> >> >>     }
> >> >> >>
> >> >> >>  This basically defines how to construct the mount strategy class
> >> and
> >> >> >> what
> >> >> >>  the params are.  One of these would need to be defined for each of
> >> >> the
> >> >> >>  half-dozen or so UrlCodingStrategies.  We could make them inner
> >> >> >> interfaces
> >> >> >>  to keep the definition with the class.
> >> >> >>
> >> >> >>  Note that this mechanism allows for easy extension by end-users.
> >> >> >>
> >> >> >>  I'm using this in my site and it is quite nice.
> >> >> >>
> >> >> >>  I'll post more details later - I'm still testing, etc.
> >> >> >>
> >> >> >>  -Doug
> >> >> >>
> >> >> >>
> >> >> >>  Johan Compagner wrote:
> >> >> >>  >
> >> >> >>  > personally i dont see any added value.
> >> >> >>  > It is stil a line of "code", no gain here.
> >> >> >>  > then scattered throughout your code base
> >> >> >>  > also you have to make sure that you can have then multiply of
> >> those
> >> >> >> mounts
> >> >> >>  > for 1 class
> >> >> >>  > i use the same pages under different mounts..
> >> >> >>  >
> >> >> >>  > also what happens if you package your pages and somebody else
> >> uses
> >> >> it
> >> >> >>  > or you start to also use them in an other project...
> >> >> >>  > But that doesnt want those mount points... what then? you cant
> >> >> remove
> >> >> >> them
> >> >> >>  > because then the first app breaks...
> >> >> >>  > I still think mounting and stuff is something the Application is
> >> >> >>  > responsible
> >> >> >>  > for not the web app itself.
> >> >> >>  >
> >> >> >>  > I could see an annotation like: @Unmountable ...
> >> >> >>  > Because it is sort of a security hole in wicket now. If a page
> >> has
> >> >> a
> >> >> >>  > default
> >> >> >>  > constructor and i know the name i could just show it... (of no
> >> >> other
> >> >> >>  > security prevents that)
> >> >> >>  > Ofcourse this is very hypothetical and not very likely that it
> >> will
> >> >> be
> >> >> >>  > abused because you have to know classnames (but these can spoil
> >> out
> >> >> >> when
> >> >> >>  > not
> >> >> >>  > carefull with shared resouces..)
> >> >> >>  >
> >> >> >>  >
> >> >> >>  > johan
> >> >> >>  >
> >> >> >>  >
> >> >> >>
> >> >> >>  --
> >> >> >>  View this message in context:
> >> >> >>
> >> >>
> >> http://www.nabble.com/how-to-contribute---wicket-1.4-plans-tp17034501p17039998.html
> >> >> >>  Sent from the Wicket - Dev mailing list archive at Nabble.com.
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >>
> >> >> --
> >> >> View this message in context:
> >> >>
> >> http://www.nabble.com/how-to-contribute---wicket-1.4-plans-tp17034501p17040515.html
> >> >> Sent from the Wicket - Dev mailing list archive at Nabble.com.
> >> >>
> >> >>
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >> http://www.nabble.com/how-to-contribute---wicket-1.4-plans-tp17034501p17046767.html
> >> Sent from the Wicket - Dev mailing list archive at Nabble.com.
> >>
> >>
> > 
> > 
> 

Reply via email to