Yeah, that's what I am thinking of. A security implementation that consists of a couple (at least two) strategies.
Eelco On 10/28/05, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > > im not saying that EVERY USER has to implement their own authentication > mechanism, im saying that EVERY IMPLEMENTATION OF THE SECURITY MECHANISM has > to provide that mechanism. > > So maybe every implementation consists of a a few classes: an implementation > of the security mechanism + a subclass of requestcycle that takes care of > the exceptions and all that stuff. > > or if you really want to have it in one place maybe we should do something > like this: > > have a WicketSecurityException class that extends a runtimeexception > and have a callback in the security interface ie > handleException(WicketSecurityException) > > then our regular request cycle can do > > if (exception instanceof WicketSecurityException) > getSecurityImpl().handleException(exception); > > that way everything is handled inside the security implementation. > > > -Igor > > > > ________________________________ > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Johan Compagner > Sent: Friday, October 28, 2005 10:43 AM > > To: wicket-develop@lists.sourceforge.net > Subject: Re: [Wicket-develop] integrating authorization > > > oure solution that maurice and i have implemented was really build with that > in mind!! > that i want to have. just a jaas implementation in wicket-extentions that > can be used as a drop in placement! > just a policy file and some tweaking for handling login and you where done. > > now you are saying that that work must be done by everybody who wants to use > security? > What is the gain then? That i can do now (building pretty much from scratch) > > Wicket defines a few interfaces and uses those interfaces at spefic points > (like page.checkAccess()) > and we have a few implementations in wicket-extentions. > That should be the goal. > > johan > > > > On 10/28/05, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > > > > Im not so sure about that. > > > > what if a component and not a page requires authentication? what if a > component only in a certain mode requires authentication? once again, too > many ifs, better to go for something very general. > > > > -Igor > > > > > > > > ________________________________ > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Johan Compagner > > Sent: Friday, October 28, 2005 10:23 AM > > > > To: wicket-develop@lists.sourceforge.net > > Subject: Re: [Wicket-develop] integrating authorization > > > > > > > > > > AuthenticationException shouldn't be a runtime that one should really be > catched by the one that is called i think. > > > > And that exception should be handled by wicket (go to a logon page) > > > > > > On 10/28/05, Igor Vaynberg <[EMAIL PROTECTED] > wrote: > > > We already have hooks in RequestCycle for handling runtime exceptions: > > > > > > protected final void internalOnRuntimeException(final > Page page, final > > > RuntimeException e) > > > throws ServletException > > > > > > { > > > > > > // Let client handle any specifics and possibly return a > > > page to redirect to > > > > > > final Page redirectTo = > application.onRuntimeException(page, > > > e); > > > > > > > > > -Igor > > > > > > > > > > -----Original Message----- > > > > From: [EMAIL PROTECTED] > > > > [mailto:[EMAIL PROTECTED] > On Behalf > > > > Of Eelco Hillenius > > > > Sent: Friday, October 28, 2005 9:30 AM > > > > To: wicket-develop@lists.sourceforge.net > > > > Subject: Re: [Wicket-develop] integrating authorization > > > > > > > > Indeed. The last thing to solve is how to enable users to > > > > elegantly hook in some mechanism that handles such an > > > > exception. To make the decission to redirect to an error page > > > > or e.g. a level-2 login page. > > > > > > > > Eelco > > > > > > > > On 10/28/05, Igor Vaynberg < [EMAIL PROTECTED]> wrote: > > > > > I think authentication is resposibility of the implementation. The > > > > > first thing the implentation should check for is if the user is > > > > > authenticated, if they are not throw an > > > > AuthenticationException, catch > > > > > it somewhere and redirect to the login page or wahtever it > > > > needs to do. > > > > > > > > > > -Igor > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: [EMAIL PROTECTED] > > > > > > [mailto: > [EMAIL PROTECTED] On Behalf Of > > > > > > Eelco Hillenius > > > > > > Sent: Friday, October 28, 2005 8:26 AM > > > > > > To: wicket-develop@lists.sourceforge.net > > > > > > Subject: Re: [Wicket-develop] integrating authorization > > > > > > > > > > > > Yes, that's the last interesting issue to solve I think. > > > > > > Something like you propose. Maybe. If we can ship 1.1. early this > > > > > > weekend, we can be working on code together right after that :). > > > > > > > > > > > > As for Maurices' question: I implemented it as a drop-in > > > > (at least > > > > > > that's the idea). > > > > > > > > > > > > Eelco > > > > > > > > > > > > > > > > > > On 10/28/05, Johan Compagner < [EMAIL PROTECTED]> wrote: > > > > > > > allowAcccess() is not needed if we let allowRender() do 2 > > > > > > things 1> > > > > > > > return a boolean that means the component is just not > > > > visible 2> > > > > > > > throw an exception. that means the component will block a > > > > > > page (this > > > > > > > exception is catched in Page.checkAccess() > > > > > > > > > > > > > > allowEnabled is for interpreting by the developer i > > > > think. If the > > > > > > > developer sees it is a text component it can use that one for > > > > > > > readonly (instead of disabled). I am fine with that it is > > > > > > the same at > > > > > > > the backend (no data can be changed) so it is only a ui > > > > > > property what > > > > > > > you want so the designer/developer can choose. > > > > > > > > > > > > > > > > > > > > > My question is (but i will look at the implementation > > > > > > eelco will make > > > > > > > :)) > > > > > > > > > > > > > > what happens if i call: > > > > > > > > > > > > > > allowRender(component) > > > > > > > > > > > > > > and i am not logged in? > > > > > > > Who is catching that? Is that the responsability of the > > > > > > > implementation of the security? Should it set a response page?? > > > > > > > But what is then thrown?? > > > > > > > > > > > > > > Page.checkAccess() > > > > > > > { > > > > > > > try > > > > > > > { > > > > > > > boolean visible = security.AllowRender(this); > > > > > > > // I think allowRender(WithAPage) should always throw an > > > > > > > exception like it should do with components that block a page. > > > > > > > // but: > > > > > > > if( !visible ) > > > > > > > { > > > > > > > // Page can't be visible but now that boolean is > > > > > > saying that > > > > > > > this was because it was not logged in? > > > > > > > setResponsePage(MyLoginPage) > > > > > > > } > > > > > > > } Catch(NotAllowedException) > > > > > > > { > > > > > > > setResponsePage(AccessDenied) > > > > > > > return false; > > > > > > > } > > > > > > > return true; > > > > > > > } > > > > > > > > > > > > > > The visible for a page would have magically have 2 things, > > > > > > I don't > > > > > > > like that the security implementation has something to do > > > > > > with pages, > > > > > > > setting response things like that > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 10/28/05, Maurice Marrink < [EMAIL PROTECTED]> > wrote: > > > > > > > > Still can't say I'm very enthusiastic about this > > > > > > interface, but it > > > > > > > > could work. > > > > > > > > IMO there are however still a few things missing in > > > > the interface. > > > > > > > > Currently it has : > > > > > > > > boolean allowCreateComponent(Class c); to allow/disallow > > > > > > component > > > > > > > > creation. > > > > > > > > If it returns false the component will throw a > > > > securityexception. > > > > > > > > > > > > > > > > boolean allowRender(Component c); to allow/disallow > > > > > > component rendering. > > > > > > > > > > > > > > > > boolean allowEnabled(Component c); to enable/disable > > > > a component. > > > > > > > > > > > > > > > > What I think is missing: > > > > > > > > boolean allowWrite(Component c); sometimes you want > > > > to set the > > > > > > > > readonly property on textfields and the like, > > > > especially since a > > > > > > > > disabled formcomponent is not submitted with the form. > > > > > > You could use > > > > > > > > allowEnabled for this in an attributemodifier but I am > > > > > > not in favor for that. > > > > > > > > > > > > > > > > boolean allowAccess(Component c); childs use this to > > > > > > block access to > > > > > > > > the parent page. In affect the page will not be rendered > > > > > > instead we > > > > > > > > might redirect to an accessdenied page. > > > > > > > > > > > > > > > > If I want to do something unusual like change the > > > > > > background color > > > > > > > > of my component based on the presence of the foobar > > > > right of the > > > > > > > > user, I would probably use an attributemodifier to do it. My > > > > > > > > implementation of the interface would contain an additional > > > > > > > > hasFoorbar check and the attributemodifier would use that. > > > > > > > > --I was trying to find an example of this interface not > > > > > > working, but > > > > > > > > I guess I've just blown it for myself ;)-- Still think > > > > > > the 2 methods > > > > > > > > above should be in the interface though. > > > > > > > > And I still don't like the fact that if we change > > > > this interface > > > > > > > > later on it will brake any existing code. > > > > > > > > > > > > > > > > Ok, so we have an interface, that is not enough to build a > > > > > > > > securityframework. What are the plans for that? > > > > > > > > I think the framework johan and I designed could very > > > > easily be > > > > > > > > adapted to use this interface instead of the > > > > > > IsecurityCheck it does now. > > > > > > > > > > > > > > > > Basicly I'm looking for answers for the following questions. > > > > > > > > Is the interface going to be a drop in > > > > > > > > (setSecurity(SecurityInterface > > > > > > > > sec) or will components implement the interface? > > > > > > > > --The drop in has my vote. > > > > > > > > How will users specify what security framework to use > > > > > > (jaas, aesgi)? > > > > > > > > (factory of some sort or do users have to set up > > > > > > everything manually > > > > > > > > and make the calls to the framework directly from within the > > > > > > > > interface) --I am in favor of the factory, but even > > > > > > without that it > > > > > > > > will be relatively easily to provide some basic > > > > implementation > > > > > > > > in wicket-extensions for jaas or aesgi. > > > > > > > > > > > > > > > > Ok, feeling better about the interface now then I did > > > > > > when I started > > > > > > > > writing it. > > > > > > > > ________________________________ > > > > > > > > > > > > > > > > Maurice Marrink > > > > > > > > www.topicus.nl > > > > > > > > -----Original Message----- > > > > > > > > From: Igor Vaynberg [mailto: [EMAIL PROTECTED] > > > > > > > > Sent: donderdag 27 oktober 2005 21:00 > > > > > > > > To: wicket-develop@lists.sourceforge.net > > > > > > > > Subject: RE: [Wicket-develop] integrating authorization > > > > > > > > > > > > > > > > What Eelco meant is that allowEnabled does not > > > > dictate component > > > > > > > > visibility, allowRender does that. If allowRender returns > > > > > > false you > > > > > > > > will never get allowEnabled callback for the same component. > > > > > > > > allowEnabled dictates whether this component is > > > > enabled - normal > > > > > > > > mode or disabled - effectively read-only mode. > > > > > > > > > > > > > > > > Our idea is to provide an interface that is > > > > completely free of > > > > > > > > implementation details, in fact it is nothing more then a > > > > > > callback > > > > > > > > interface for certain places in component lifecycle. > > > > > > > > > > > > > > > > -Igor > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: > [EMAIL PROTECTED] > > > > > > > > > > [mailto:[EMAIL PROTECTED] On > > > > > > > Behalf > > > > > > > > > Of Maurice Marrink > > > > > > > > > Sent: Thursday, October 27, 2005 12:52 AM > > > > > > > > > To: wicket-develop@lists.sourceforge.net > > > > > > > > > Subject: RE: [Wicket-develop] integrating authorization > > > > > > > > > > > > > > > > > > Not sure i get what isn't, but disabling components > > > > > > based on user > > > > > > > > > authorization is also exactly what we need for our project. > > > > > > > > > > > > > > > > > > Yes throwing an exception should do the same trick. > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > > > > > > > > > Maurice Marrink > > > > > > > > > www.topicus.nl > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Eelco Hillenius [mailto:[EMAIL PROTECTED] ] > > > > > > > > > Sent: donderdag 27 oktober 2005 1:36 > > > > > > > > > To: wicket-develop@lists.sourceforge.net > > > > > > > > > Subject: Re: [Wicket-develop] integrating authorization > > > > > > > > > > > > > > > > > > Nope it isn't. It is one of the main things I want > > > > to use in > > > > > > > > > my current project. Not rendering components based on the > > > > > > > > > current roles of a user. Kind of like portal functionality. > > > > > > > > > > > > > > > > > > I didn't really think of the case of letting one > > > > > > component trigger > > > > > > > > > a page to be invalid. I see... good case too. I think > > > > > > that might > > > > > > > > > be an implementation detail though. Instead of > > > > returning the > > > > > > > > > boolean, a component may still throw an auth > > > > related exception. > > > > > > > > > That should work, right? > > > > > > > > > > > > > > > > > > Eelco > > > > > > > > > > > > > > > > > > > > > > > > > > > On 10/26/05, Maurice Marrink <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > and Links/Labels are using allowEnabled for there > > > > > > visible state. > > > > > > > > > > Now that's great I wonder why we haven't thought of that > > > > > > > > > before, we'll > > > > > > > > > just > > > > > > > > > > use allowEnabled to dictate a components visibility!. It > > > > > > > > > makes so much > > > > > > > > > > sense! > > > > > > > > > > Sorry for being sarcastic here but is getting late :) You > > > > > > > > > can't have > > > > > > > > > > allowEnabled doing double duty here it will confuse the > > > > > > > > > hell > > > > > > > > > > out of people. > > > > > > > > > > But johan is right we need a way of letting a component / > > > > > > > > > model block > > > > > > > > > access > > > > > > > > > > to a page completely or just allow the page to be > > > > > > displayed but > > > > > > > > > > not > > > > > > > > > the > > > > > > > > > > component itself. > > > > > > > > > > And you know what, we already can by using actions > > > > > > like access, > > > > > > > > > > read > > > > > > > > > and > > > > > > > > > > write. If something does not have access it blocks > > > > > > the page, if > > > > > > > > > > it > > > > > > > > > does not > > > > > > > > > > have read the page will display but not the component. > > > > > > > > > > > > > > > > > > > > Maurice > > > > > > > > > > > > > > > > > > > > ________________________________________ > > > > > > > > > > From: > [EMAIL PROTECTED] > > > > > > > > > > [mailto: > [EMAIL PROTECTED] ] > > > > > > > On > > > > > > > > > Behalf Of Johan > > > > > > > > > > Compagner > > > > > > > > > > Sent: donderdag 27 oktober 2005 1:14 > > > > > > > > > > To: wicket-develop@lists.sourceforge.net > > > > > > > > > > Subject: Re: [Wicket-develop] integrating authorization > > > > > > > > > > > > > > > > > > > > yes that i did get. > > > > > > > > > > So if one component on the page returns false for > > > > > > > > > allowRender() then > > > > > > > > > > the page it self is not visible (allowAccess() failes) > > > > > > > > > > > > > > > > > > > > and Links/Labels are using allowEnabled for there > > > > > > visible state. > > > > > > > > > > > > > > > > > > > > On 10/27/05, Eelco Hillenius > > > > > > <[EMAIL PROTECTED] > wrote: > > > > > > > > > > It works exactly like isVisible, with the exception > > > > > > that it will > > > > > > > > > > allways overrule isVisible (I'll put that in the docs). > > > > > > > > > > > > > > > > > > > > Eelco > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 10/26/05, Johan Compagner < > > > > [EMAIL PROTECTED] > wrote: > > > > > > > > > > > where will allowRender() be called in wicket? > > > > > > > > > > >I think the most logical first place it the > > > > > > Page.checkAccess() > > > > > > > > > > >or > > > > > > > > > > > Page.checkSecurity() that is also called besides > > > > > > checkAccess() > > > > > > > > > > > > > > > > > > > > > >Does then the implementation do the compleet check > > > > > > for the page? > > > > > > > > > > >So the page itself and then all the components > > > > on the page? > > > > > > > > > > >But how does it check the components and there > > > > model data? > > > > > > > > > > >( think > > > > > > > > > models > > > > > > > > > > > > > > > > > > > > > need some kind of marker interface like SecurityModel) > > > > > > > > > > > > > > > > > > > > > >Because it can be that a form's model data is saying i > > > > > > > > > > >can't render > > > > > > > > > so > > > > > > > > > > the > > > > > > > > > > > page can be renderd > > > > > > > > > > >But a link can also say i can't be renderd but that > > > > > > > > > doesn't mean the > > > > > > > > > page > > > > > > > > > > > > > > > > > > > > > can't be rendered (just the link can't be rendered) > > > > > > > > > > > > > > > > > > > > > >Or if allowRender() is false in any > > > > component/model on the > > > > > > > > > page then > > > > > > > > > the > > > > > > > > > > > complete page can't be rendered but then > > > > > > allowEnabled is used > > > > > > > > > > >to say to a link that it can't be > > > > > > > > > visible > > > > > > > > > > (so > > > > > > > > > > > there are no non enabled links they are always not > > > > > > > > > > > rendered) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 10/27/05, Eelco Hillenius < > > > > > > [EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > > > > > > > > > Here's the interface method we (Jonathan, Igor > > > > > > and I) think > > > > > > > > > > > > will > > > > > > > > > work: > > > > > > > > > > > > > > > > > > > > > > > > /** > > > > > > > > > > > >* Checks whether an instance of the given > > > > > > component class may > > > > > > > > > > be > > > > > > > > > > > created. > > > > > > > > > > > >* If this method returns false, a [EMAIL PROTECTED] > > > > > > > > > > AuthorizationException} > > > > > > > > > > > is thrown > > > > > > > > > > > >* in during construction. > > > > > > > > > > > >* > > > > > > > > > > > >* @param c > > > > > > > > > > > >*the component to check for > > > > > > > > > > > >* @return whether the given component may be > > > > created */ > > > > > > > > > > > >boolean allowCreateComponent(Class c); > > > > > > > > > > > > > > > > > > > > > > > > /** > > > > > > > > > > > >* Gets whether the given component may be rendered. If > > > > > > > > > > > >this > > > > > > > > > > > method returns > > > > > > > > > > > >* false, the component is not rendered, and > > > > > > neither are it's > > > > > > > > > > > children. > > > > > > > > > > > >* > > > > > > > > > > > >* @param c > > > > > > > > > > > >*the component to check for > > > > > > > > > > > >* @return whether the given component may be > > > > rendered */ > > > > > > > > > boolean > > > > > > > > > > > >allowRender(Component c); > > > > > > > > > > > > > > > > > > > > > > > > /** > > > > > > > > > > > >* <p> > > > > > > > > > > > >* Gets whether a component is allowed to be > > > > > > enabled. If this > > > > > > > > > > > method returns > > > > > > > > > > > >* true, a component may decide by itself > > > > (typically using > > > > > > > > > > > >it's > > > > > > > > > > > enabled > > > > > > > > > > > >* property) whether it is enabled or not. If > > > > this method > > > > > > > > > > returns > > > > > > > > > > > false, the > > > > > > > > > > > >* passed component is marked disabled, regardless it's > > > > > > > > > > > >enabled > > > > > > > > > > > property. > > > > > > > > > > > >* </p> > > > > > > > > > > > >* <p> > > > > > > > > > > > >* When a component is not allowed to be enabled (in > > > > > > > > > > > >effect > > > > > > > > > > > disabled through > > > > > > > > > > > >* the implementation of this interface), > > > > Wicket will try > > > > > > > > > > > >to > > > > > > > > > > > prevent model > > > > > > > > > > > >* updates too. This is not completely fail safe, as > > > > > > > > > > > >constructs > > > > > > > > > > > like: > > > > > > > > > > > >* > > > > > > > > > > > >* <pre> > > > > > > > > > > > >* User u = (User)getModelObject(); > > > > > > > > > > > >* u.setName ("got you there!"); > > > > > > > > > > > >* </pre> > > > > > > > > > > > >* > > > > > > > > > > > >* can't be prevented. Indeed it can be argued that > > > > > > any model > > > > > > > > > > > protection is > > > > > > > > > > > >* best dealt with in your model objects to be > > > > completely > > > > > > > > > > secured. > > > > > > > > > > > Wicket > > > > > > > > > > > >* will catch all normal use though. > > > > > > > > > > > >* > > > > > > > > > > > >* </p> > > > > > > > > > > > >* > > > > > > > > > > > >* @param c > > > > > > > > > > > >*the component to check for > > > > > > > > > > > >* @return whether a component is allowed to be enabled > > > > > > > > > */ boolean > > > > > > > > > > > >allowEnabled(Component c); > > > > > > > > > > > > > > > > > > > > > > > > Eelco > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 10/26/05, Eelco Hillenius < > > > > > > [EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > Well, then there's no special wicket > > > > support for that > > > > > > > > > nescesarry > > > > > > > > > > either. > > > > > > > > > > > > > > > > > > > > > > > > > > >I only want to test at a certain point what is > > > > > > inside the > > > > > > > > > model. > > > > > > > > > > And > > > > > > > > > > > if a > > > > > > > > > > > > > > user can see that object and if he can see it > > > > > > if he can > > > > > > > > > > > > > >alter it. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > > > > > > > > > This SF.Net email is sponsored by the JBoss Inc. > > > > > > > > > > > > Get Certified Today * Register for a JBoss > > > > > > Training Course > > > > > > > > > > > > Free Certification Exam for All Training > > > > > > Attendees Through > > > > > > > > > > > > End of > > > > > > > > > 2005 > > > > > > > > > > > > Visit > http://www.jboss.com/services/certification > > > > > > > for > > > > > > > > > > > more information > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > Wicket-develop mailing list > > > > > > > > > > > > Wicket-develop@lists.sourceforge.net > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > > > > > > > This SF.Net email is sponsored by the JBoss Inc. > > > > > > > > > > Get Certified Today * Register for a JBoss Training > > > > > > Course Free > > > > > > > > > > Certification Exam for All Training Attendees > > > > Through End of > > > > > > > > > > 2005 Visit > http://www.jboss.com/services/certification for > > > > > > > more > > > > > > > > > information > > > > > > > > > > > _______________________________________________ > > > > > > > > > > Wicket-develop mailing list > > > > > > > > > > Wicket-develop@lists.sourceforge.net > > > > > > > > > > > > > > > > > > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > > > > > > > This SF.Net email is sponsored by the JBoss Inc. > > > > > > > > > > Get Certified Today * Register for a JBoss Training > > > > > > Course Free > > > > > > > > > > Certification Exam for All Training Attendees > > > > Through End of > > > > > > > > > > 2005 Visit > http://www.jboss.com/services/certification for > > > > > > > more > > > > > > > > > information > > > > > > > > > > > _______________________________________________ > > > > > > > > > > Wicket-develop mailing list > > > > > > > > > > Wicket-develop@lists.sourceforge.net > > > > > > > > > > > > > > > > > > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > > > > > > This SF.Net email is sponsored by the JBoss Inc. > > > > > > > > > Get Certified Today * Register for a JBoss Training Course > > > > > > > > > Free Certification Exam for All Training Attendees Through > > > > > > End of 2005 > > > > > > > > > Visit > > > > > > > http://www.jboss.com/services/certification > > > > > > > > > for more information > > > > > > > _______________________________________________ > > > > > > > > > Wicket-develop mailing list > > > > > > > > > Wicket-develop@lists.sourceforge.net > > > > > > > > > > > > > > > > > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > > > > > > This SF.Net email is sponsored by the JBoss Inc. > > > > > > > > > Get Certified Today * Register for a JBoss Training Course > > > > > > > > > Free Certification Exam for All Training Attendees Through > > > > > > End of 2005 > > > > > > > > > Visit > > > > > > > http://www.jboss.com/services/certification > > > > > > > > > for more information > > > > > > > _______________________________________________ > > > > > > > > > Wicket-develop mailing list > > > > > > > > > Wicket-develop@lists.sourceforge.net > > > > > > > > > > > > > > > > > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > > > > > This SF.Net email is sponsored by the JBoss Inc. > > > > > > > > Get Certified Today * Register for a JBoss Training > > > > Course Free > > > > > > > > Certification Exam for All Training Attendees Through End of > > > > > > > > 2005 Visit > http://www.jboss.com/services/certification for > > > > > > > more information > > > > > > > > > _______________________________________________ > > > > > > > > Wicket-develop mailing list > > > > > > > > Wicket-develop@lists.sourceforge.net > > > > > > > > > > > > > > > > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > > > > > This SF.Net email is sponsored by the JBoss Inc. > > > > > > > > Get Certified Today * Register for a JBoss Training > > > > Course Free > > > > > > > > Certification Exam for All Training Attendees Through End of > > > > > > > > 2005 Visit > http://www.jboss.com/services/certification for > > > > > > > more information > > > > > > > > > _______________________________________________ > > > > > > > > Wicket-develop mailing list > > > > > > > > Wicket-develop@lists.sourceforge.net > > > > > > > > > > > > > > > > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > > > This SF.Net email is sponsored by the JBoss Inc. > > > > > > Get Certified Today * Register for a JBoss Training Course Free > > > > > > Certification Exam for All Training Attendees Through End of 2005 > > > > > > Visit http://www.jboss.com/services/certification > > > > > > for more information > > > > _______________________________________________ > > > > > > Wicket-develop mailing list > > > > > > Wicket-develop@lists.sourceforge.net > > > > > > > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > > This SF.Net email is sponsored by the JBoss Inc. > > > > > Get Certified Today * Register for a JBoss Training Course Free > > > > > Certification Exam for All Training Attendees Through End of 2005 > > > > > Visit http://www.jboss.com/services/certification > for more > > > > information > > > > > _______________________________________________ > > > > > Wicket-develop mailing list > > > > > Wicket-develop@lists.sourceforge.net > > > > > > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > This SF.Net email is sponsored by the JBoss Inc. > > > > Get Certified Today * Register for a JBoss Training Course > > > > Free Certification Exam for All Training Attendees Through > > > > End of 2005 Visit > http://www.jboss.com/services/certification > > > > for more information > _______________________________________________ > > > > Wicket-develop mailing list > > > > Wicket-develop@lists.sourceforge.net > > > > > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > This SF.Net email is sponsored by the JBoss Inc. > > > Get Certified Today * Register for a JBoss Training Course > > > Free Certification Exam for All Training Attendees Through End of 2005 > > > Visit http://www.jboss.com/services/certification for > more information > > > _______________________________________________ > > > Wicket-develop mailing list > > > Wicket-develop@lists.sourceforge.net > > > > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > > > > > > > ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information _______________________________________________ Wicket-develop mailing list Wicket-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-develop