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.
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/how-to-contribute---wicket-1.4-plans-tp17034501p17048610.html
Sent from the Wicket - Dev mailing list archive at Nabble.com.
