A user-contrib wiki page could be a good place to start, though wikis tend to be harder to maintain over time (since they're not versioned and info there can get stale).
IMHO, for feature samples, blog-land and the beehive-user@ list are great since they're searchable, and we can bring into SVN those that are of general interest. For things like a Maven plug-in (things which aren't feature samples), a java.net / sourceforge project would be a great place to have those contributions go until we bring some of these into Beehive SVN. If there's enough interest, we could also do a user-contrib sample app in a non-ASF repository -- would be easier for non-committers to make changes there. ... Eddie On 5/22/05, Richard Feit <[EMAIL PROTECTED]> wrote: > Hi all, > > Any ideas on where/how we could offer a place for users to post > samples? It would really fill out our doc/samples/education story, and > it's a great way to build community around this stuff. Thoughts? > > Rich > > -------- Original Message -------- > Subject: Re: question about inheritance > Date: Mon, 23 May 2005 05:10:47 +1000 > From: Adam Jenkins <[EMAIL PROTECTED]> > Reply-To: Beehive Users <[email protected]>, > [EMAIL PROTECTED] > To: Beehive Users <[email protected]> > References: <[EMAIL PROTECTED]> > <[EMAIL PROTECTED]> > <[EMAIL PROTECTED]> > <[EMAIL PROTECTED]> > <[EMAIL PROTECTED]> > <[EMAIL PROTECTED]> > <[EMAIL PROTECTED]> > <[EMAIL PROTECTED]> > <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> > > > > Hi Rich, > > I'm working on a very simple example currently (to teach myself the tech > before tackling anything production related). The two pieces of > functionality I'm looking at are logging in and building/deploying with > maven. > > I'd be happy to doc up what we've been discussing and send you that and > the code to use as a sample if you're intestested. I'm probably a week > or so away from finished though. > > Cheers > Adam > > On Sat, 2005-05-21 at 23:37 -0600, Richard Feit wrote: > > Hi Adam, > > > > The login/logout methods are currently only called from the base > > FlowController.login() and FlowController.logout() convenience methods > > (which can be called directly from Page Flow actions). But you can > > always get the current LoginHandler by calling Handlers.get( > > servletContext ).getLoginHandler(). > > > > I'm going to try and get a login example into the distribution sometime > > tomorrow -- it's always one of the first things people want to do. > > > > Let me know if you have more questions about this. > > > > Rich > > > > Adam Jenkins wrote: > > > > >Hi Rich, > > > > > >I've written my own LoginHandler and registered it in > > >beehive-netui-config.xml. I was just wondering about the > > >method: > > > > > >public void login(final FlowControllerHandlerContext context, final > > >String username, final String password) > > > > > >How do I have this method called? Do I call it directly (in which case, > > >where do I get the reference to the current login handler from?), or is > > >there a framework specific way to activate a 'login' action, maybe > > >through an annotation or something? > > > > > >Do you know of any examples of using a LoginHandler and the > > >'loginRequired' annotation anywhere? > > > > > >Cheers > > >Adam > > > > > >On Fri, 2005-05-20 at 18:19 -0600, Richard Feit wrote: > > > > > > > > >>Hi Adam, > > >> > > >>You're right -- it should return null (so it acts like > > >>HttpServletRequest.getUserPrincipal()). I'll update the javadoc for this. > > >> > > >>Thanks, > > >>Rich > > >> > > >>Adam Jenkins wrote: > > >> > > >> > > >> > > >>>Hi Again Rich, > > >>> > > >>>I'm writing an implementation of the LoginHandler to solve my > > >>>requirements. The method getUserPrincipal(), should I return null from > > >>>that method if the user hasn't yet logged in? The javadoc doesn't say > > >>>and there are no exceptions signified to use. > > >>> > > >>>Cheers > > >>>Adam > > >>> > > >>>On Fri, 2005-05-20 at 14:14 -0600, Richard Feit wrote: > > >>> > > >>> > > >>> > > >>> > > >>>>Thank you! :) > > >>>>Hopefully you'll continue to find that it's got what you need, and where > > >>>>it doesn't, we'd love to get bugs/feature-requests, or better yet, to > > >>>>have people get involved. > > >>>> > > >>>>The questions are great for us to hear -- they give us a sense for where > > >>>>we've done things well and where there are holes... and where we need to > > >>>>fill in the docs. > > >>>> > > >>>>Oh, and if it *is* good, getting the word out definitely helps the > > >>>>project. :) > > >>>> > > >>>>Rich > > >>>> > > >>>>Adam Jenkins wrote: > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>>><explitative> awesome! > > >>>>> > > >>>>>Wow, talk about spoilt for choice! :) Each of those answers not only > > >>>>>help, but that's fantastic information to know for other uses. > > >>>>> > > >>>>>A big well done to all the people that worked on this. My entire team > > >>>>>(all fairly senior developers) are continually blown away by not just > > >>>>>the things that beehive does, but that lateral thinking that went into > > >>>>>it's creation. > > >>>>> > > >>>>>It's good to see programming of this calibre. Very inspiring to others > > >>>>>in the field. Cheers for all the hard work and such a quick response > > >>>>>to > > >>>>>my questions. > > >>>>> > > >>>>>Thanks again > > >>>>>Adam > > >>>>> > > >>>>>On Fri, 2005-05-20 at 13:10 -0600, Richard Feit wrote: > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>>>Hi Adam, > > >>>>>> > > >>>>>>These are great questions. A few responses; hopefully one or more > > >>>>>>will > > >>>>>>help you. > > >>>>>> > > >>>>>> - You can override beforeAction()/afterAction() on either the base > > >>>>>>class or the derived class. This is a brute-force way to run code > > >>>>>>before/after every action. In the beforeAction method, you could even > > >>>>>>write code to read the action method's annotations through reflection, > > >>>>>>and look for a custom annotation that you wrote to determine whether > > >>>>>>to > > >>>>>>do the check and throw an exception if necessary. > > >>>>>> > > >>>>>> - We do have the idea of "action interceptors". An action > > >>>>>>interceptor is a class that can be configured to run before/after a > > >>>>>>particular action, or all actions, or all actions in a particular page > > >>>>>>flow. It can do things like change/cancel the destination URI, throw > > >>>>>>an > > >>>>>>exception, or "inject" an entire nested page flow to run before the > > >>>>>>action. These are registered in WEB-INF/beehive-netui-config.xml. > > >>>>>>There's a bit of doc on this at > > >>>>>>http://incubator.apache.org/beehive/pageflow/config/beehive-netui-config.html#pageflow-action-interceptors > > >>>>>>. But what you *really* want is a "named" action interceptor that you > > >>>>>>can refer to in an annotation. Short of that, you could write an > > >>>>>>interceptor that would use the reflection/annotation-based approach I > > >>>>>>mentioned above. But read on... > > >>>>>> > > >>>>>> - In this specific case our annotations can help you do what you > > >>>>>>want. If you set the 'loginRequired' attribute on an action (or on > > >>>>>>the > > >>>>>>page flow class, in @Jpf.Controller, which can be overridden on a > > >>>>>>per-action basis), then a NotLoggedInException will be thrown if you > > >>>>>>hit > > >>>>>>the action without being logged in. By default, "being logged in" > > >>>>>>means > > >>>>>>that getUserPrincipal() returns a non-null value on the request; > > >>>>>>however, you can plug in your own login behavior. To do this, you'd > > >>>>>>implement org.apache.beehive.netui.pageflow.handler.LoginHandler, and > > >>>>>>register your class under <login-handler> in > > >>>>>>WEB-INF/beehive-netui-config.xml. > > >>>>>> > > >>>>>>Hope this helps -- let me know if you need more info on any of this. > > >>>>>> > > >>>>>>Rich > > >>>>>> > > >>>>>>Adam Jenkins wrote: > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>>>Hi Rich, > > >>>>>>> > > >>>>>>>Thanks for the quick response. That's excellent info, it answers > > >>>>>>>about > > >>>>>>>3/4 of what I was after. I have one more small question about > > >>>>>>>executing > > >>>>>>>the assertion. > > >>>>>>> > > >>>>>>>Lets say I have a controller (and my syntax could be wrong here, I'm > > >>>>>>>still getting my head around beehive, but I think it get's what I'm > > >>>>>>>trying to achieve accross): > > >>>>>>> > > >>>>>>>@Jpf.Controller( > > >>>>>>> simpleActions={ > > >>>>>>> @Jpf.Forward(name="not_authenticated" path="login.do") > > >>>>>>> } > > >>>>>>> catches={ > > >>>>>>> @Jpf.Catch(type=UserNotLoggedInException.class > > >>>>>>> method="forceLogin") > > >>>>>>> } > > >>>>>>>) > > >>>>>>>public clas Base extends PageFlowController{ > > >>>>>>> > > >>>>>>> private void assertUserLoggedIn(...) throws > > >>>>>>> UserNotLoggedInException{ > > >>>>>>> //do some stuff to make sure the user is validated. > > >>>>>>> } > > >>>>>>> > > >>>>>>> public Forward forceLogin(...){ > > >>>>>>> return new Forward("not_authenticated"); > > >>>>>>> } > > >>>>>>>} > > >>>>>>> > > >>>>>>>Now, I want to call assertUserLoggedIn before any action is executed > > >>>>>>>and > > >>>>>>>I want it on almost every action in the system (except of course the > > >>>>>>>'login' action). I would normally do this in a superclass of all the > > >>>>>>>struts actions I used. That is, I would call assertUserLoggedIn in > > >>>>>>>the > > >>>>>>>super class struts action and, if the exception was thrown it would > > >>>>>>>be > > >>>>>>>handled by the global exception handling. If no exception was > > >>>>>>>thrown, I > > >>>>>>>would then call an abstract method that is implemented in the > > >>>>>>>subclass > > >>>>>>>that actually does the processing and returns the forward. That was > > >>>>>>>my > > >>>>>>>way of enforcing that the first thing every action did was check and > > >>>>>>>make sure that the user was in fact logged in. So, in a nut shell, > > >>>>>>>is > > >>>>>>>there a way to call a common assertion or set of assertions (or set > > >>>>>>>of > > >>>>>>>methods for that matter) from a whole set of actions without actually > > >>>>>>>specifying the assertions at the start of every action (think > > >>>>>>>crosscutting). How would you recommend achieving something like > > >>>>>>>that in > > >>>>>>>beehive? > > >>>>>>> > > >>>>>>>Cheers > > >>>>>>>Adam > > >>>>>>> > > >>>>>>>On Thu, 2005-05-19 at 17:14 -0600, Richard Feit wrote: > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>>>Hi Adam, > > >>>>>>>> > > >>>>>>>>Beehive does support inheritance in page flows (and in controls, for > > >>>>>>>>that matter). The important point for page flows is that the base > > >>>>>>>>and > > >>>>>>>>derived @Jpf.Controller annotations are merged. So if you have the > > >>>>>>>>following hierarchy: > > >>>>>>>> > > >>>>>>>> @Jpf.Controller( > > >>>>>>>> nested=true, > > >>>>>>>> catches={ > > >>>>>>>> @Jpf.Catch(type=Exception1.class, > > >>>>>>>> method="handleException1") > > >>>>>>>> } > > >>>>>>>> ) > > >>>>>>>> public class Base extends PageFlowController ... > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> @Jpf.Controller( > > >>>>>>>> catches={ > > >>>>>>>> @Jpf.Catch(type=Exception2.class, > > >>>>>>>> method="handleException2") > > >>>>>>>> } > > >>>>>>>> ) > > >>>>>>>> public class Derived1 extends Base ... > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> @Jpf.Controller( > > >>>>>>>> catches={ > > >>>>>>>> @Jpf.Catch(type=Exception3.class, > > >>>>>>>> method="handleException3") > > >>>>>>>> } > > >>>>>>>> ) > > >>>>>>>> public class Derived2 extends Derived1 ... > > >>>>>>>> > > >>>>>>>>...then the @Jpf.Controller annotation for Derived2 is virtually > > >>>>>>>>this: > > >>>>>>>> > > >>>>>>>> @Jpf.Controller( > > >>>>>>>> nested=true, > > >>>>>>>> catches={ > > >>>>>>>> @Jpf.Catch(type=Exception1.class, > > >>>>>>>> method="handleException1") > > >>>>>>>> @Jpf.Catch(type=Exception2.class, > > >>>>>>>> method="handleException2") > > >>>>>>>> @Jpf.Catch(type=Exception3.class, > > >>>>>>>> method="handleException3") > > >>>>>>>> } > > >>>>>>>> ) > > >>>>>>>> > > >>>>>>>>Additionally, action methods, exception handler methods, and > > >>>>>>>>annotated > > >>>>>>>>control fields are all inherited as long as they're not private. > > >>>>>>>> > > >>>>>>>>Does this answer your question? > > >>>>>>>> > > >>>>>>>>Rich > > >>>>>>>> > > >>>>>>>>Adam Jenkins wrote: > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>>>Hi All, > > >>>>>>>>> > > >>>>>>>>>I'm starting out with beehive and wondering about inheritance. > > >>>>>>>>>With > > >>>>>>>>>struts apps, I would put security assertions in a super class of > > >>>>>>>>>all > > >>>>>>>>>actions and redirect any exceptions thrown to the appropriate > > >>>>>>>>>page. Is > > >>>>>>>>>there a way to do similar in beehive or do you have to use shared > > >>>>>>>>>flows > > >>>>>>>>>for common stuff like that. > > >>>>>>>>> > > >>>>>>>>>Cheers > > >>>>>>>>>Adam > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>> > > >>> > > >>> > > >>> > > > > > > > > > > > > > > >
