Re: [Stripes-users] Maven convention
Thanks for the offering mate ! The Stripes mvn build is almost good now. There's just this ugly test module (as you could see it yourself), but apart from that most of it works perfect. I mean, we gen the taglib descriptors etc, sign the jars etc... There are a few glitches, but overall, it works fine. We're just waiting for Ben's green light before a directory structure refactoring, and it'll be perfect... He won't be long now : he managed to change all the version numbers etc yesterday, deploy to central (yes yes !!)... I think he's beginning his love affair with maven, but he won't say it yet :P Cheers Remi 2010/11/10 Nathan Maves > For what it is worth I can personally tell you that we (MyBatis.org) > team are working hard to achieve this same goal. We now have around 6 > sub maven project along with the core maven project. It has really > helped us deliver faster and more stable releases. It has also > allowed us to engage more people from the community to help with > development. I would love to see the Stripes community follow suit. > > Just last week I was trying to find where the unit tests for Stripes > were located. To my surprise they are not in the core module. I also > just spent a few minutes trying to find the maven page on the website, > which I have found in the past, and I can't seem to find it again. I > would love to see something as simple as > http://code.google.com/p/mybatis/wiki/DocMavenTutorial. > > For those that are still using Ant you really just need to give it a > try. I honestly have never seen someone who gives maven a try for > their build process ever go back to Ant. For a product who believes > in convention over configuration I really think it is a perfect fit > for Stripes. > > I am offering up any help or advice that you may need from myself or > the MyBatis team. > > Nathan > > On Wed, Nov 10, 2010 at 7:05 AM, Joaquin Valdez > wrote: > > > > Thanks Ben! > > On Nov 10, 2010, at 5:54 AM, Ben Gunter wrote: > > > > Thanks. That's exactly what I did, and it must have worked! > > > > http://repo2.maven.org/maven2/net/sourceforge/stripes/stripes/1.5.4/ > > > > On Wed, Nov 10, 2010 at 5:35 AM, VANKEISBELCK Remi > wrote: > >> > >> Not sure it's not too late, but anyway... > >> > >> The gpg thing is in the maven build if I remember well, there's a maven > plugin for that. You just need pgp on the build machine, with a pubkey that > you have distributed on the PGP network... then mvn clean deploy -Prelease > if I'm right : this pushes everything on sonatype's repo. > >> Then, on sonatype, just close the staging request and release. > >> > >> Cheers > >> > >> Remi > >> > >> 2010/11/10 Ben Gunter > >>> > >>> I'm working on releasing 1.5.4 now, but I can't promise I'll get it > done tonight. There's some stuff involved I've never done, like GPG signing > the artifacts and getting them synced to central through Sonatype. If I > screw something up, the release will be delayed. > >>> > >>> -Ben > >>> > >>> On Sun, Nov 7, 2010 at 9:09 PM, Nikolaos Giannopoulos < > nikol...@brightminds.org> wrote: > > Samuel, > > I am very much in favour of Maven on any project to the point that I > have been very vocal about Stripes and Maven support. > > However, I would agree with Ben that for 1.5.4 that we just keep > things as they are. In fact, I think 1.5.4 has stewed long enough and > should be officially released as we are approaching a year since the release > of 1.5.3. As I have mentioned a number of times "perception" is key in > software IMHO and a release of 1.5.4 trumps internal project changes - at > least for me. > > Speaking of which: > > Ben: Any idea when 1.5.4 will be released? It contains a lot of key > fixes and it has baked long enough? No??? > > --Nikolaos > > > > > Samuel Santos wrote: > > Ben, > > Consider this as an excuse to optimize our code structure ;) > > Cheers, > > -- > Samuel Santos > http://www.samaxes.com/ > > > On Fri, Nov 5, 2010 at 2:04 PM, Ben Gunter > wrote: > > > > This is something we can consider after the release of 1.5.4. I > didn't feel the need to add a Maven build in the first place, and I surely > don't like the idea of having to move stuff all around to accommodate it so > there will be resistance. > > > > -Ben > > > > On Sun, Oct 31, 2010 at 11:17 AM, VANKEISBELCK Remi > wrote: > >> > >> Hi Nathan, > >> > >> In order to keep the current tooling (ant, ide settings, scripts, > etc) working, and to get the first maven build working smoothly without > being intrusive, it has been agreed that nothing had to be changed. > >> > >> Now that it works, I already talked about some refactoring of the > folders to allow less config in poms, and more importantly, to allow tests > to be in the same module than the core code. > >> > >>
Re: [Stripes-users] Maven convention
On 09-11-2010 at 12:17, Samuel Santos wrote: > I do agree that we should at least add the support for Java Authentication > and Authorization Service (JAAS) to Stripes core. Maybe I'm being silly here, but why? I mean, every servlet container and application server supports JAAS (the authentication part at least). I already can add authentication using web.xml, and the only tricky part here is that often my server needs to use my DB queries (which JBoss already had an excellent solution for years ago, IMHO). And honestly, I've not yet encountered a situation where JAAS authorization was used. I know that JAAS authorization can be used for user authorization, but specifying the permissions for users and objects in a dynamic way using JAAS is just too complicated. There are many frameworks offering an easier solution for this. There are only two reasons why I'd implement authentication using a filter: 1. When I want the HttpServletRequest.getUserPrincipal() to return a (proxy to a) domain object, or 2. When I want to use the JAAS LoginModule to it's full extend (i.e. create a login wizard using multiple calls to CallbackHandler.handle(Callback[]), like com.sun.security.auth.callback.TextCallbackHandler implicitly does). Please don't get me wrong: I think it is good to raise the security issue. It simply is that important. Maybe what I'm missing is consensus on what security means. I've seen it used as any combination of the following: - authentication (a user is who he says he is) - authorization (a user is allowed to do X, Y and Z, byt not F) - accountability (on this date & time, user X did Y) - extra confirmations (authenticating individual transactions, displaying extra information, etc. to combat cross-site scripting and other hacks) - data satefy(the C&D from ACID, and backups; a stretch, but ok) - SLA & uptime guarantees (this one surprised me) Oscar -- ,-_ Oscar Westra van Holthe - Kind http://www.xs4all.nl/~kindop/ /() ) (__ ( Progress is made by lazy men looking for easier ways to do things. =/ () -- Robert Heinlein signature.asc Description: Digital signature -- Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Maven convention
On Nov 11, 2010, at 6:26 AM, Oscar Westra van Holthe - Kind wrote: > And honestly, I've not yet encountered a situation where JAAS authorization > was used. I know that JAAS authorization can be used for user authorization, > but specifying the permissions for users and objects in a dynamic way using > JAAS is just too complicated. There are many frameworks offering an easier > solution for this. > > There are only two reasons why I'd implement authentication using a filter: > 1. When I want the HttpServletRequest.getUserPrincipal() to return a (proxy > to a) domain object, or > 2. When I want to use the JAAS LoginModule to it's full extend (i.e. create a > login wizard using multiple calls to CallbackHandler.handle(Callback[]), > like com.sun.security.auth.callback.TextCallbackHandler implicitly does). And Stripes has nothing to do with JAAS, or security for that matter. The fact that we have a convenient Security Interceptor is just that -- convenience. Now, if someone proposed extending stripes to add ROLE checks much like what JEE does already, but down to the event level, I'd be keen to read about such a proposal. Something that lets folks declaratively annotate events for certain roles, etc. Perhaps reusing the existing JEE annotation that they already have on the EJB tier (not quite sure how that would work out, but...its an idea). But if you were to do that, I'd rather it be off of the standard security mechanisms already in place within the Servlet container (i.e checking the getUserPrincipal, and isUserInRole). If someone wanted to integrate something like Acegi on the front end, but have it still work with a common set of annotations, that might be nice too. But, in theory Acegi can integrate with the existing JEE infrastructure, so I don't know what that really buys anyone. Unfortunately, this is easier said than done, especially before Servlet 3.0. It gets very container specific, especially if you want to propagate the credentials back to the EJB tier in a JEE server. However, there's nothing stopping Stripes from leveraging the existing infrastructure even if it doesn't provide a way to programmatically set the role and principle. If someone uses out of the box Form or BASIC security, the @Role or whatever annotations will do the trick. I know we have our own custom login handler and our own realm for GlassFish, using its programmatic login so it all works within the framework of the JEE server. But its also GF specific, we'd have to port that were we to go to another server. As far as implementing those modules and such in Stripes, that's not its role, frankly. We use Stripes for login forms, and feed those inputs in to our security mechanism. We use a Filter like every one else, but rely on the Principals and Roles back on the EJB tier. Regards, Will Hartung -- Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev ___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
Re: [Stripes-users] Maven convention
On 11-11-2010 at 20:57, Will Hartung wrote: [...] > Unfortunately, this is easier said than done, especially before Servlet > 3.0. It gets very container specific, especially if you want to propagate > the credentials back to the EJB tier in a JEE server. Here you touch the heart of many problems: AFAIK, overriding the JavaEE authentication mechanism and then propagating it to the EJB tier so it can be used by the standard mechanisms is container specific. It's probably easier (for local EJB's at least) to create an entire framework using a session variable, and ditch the standard mechanism altogether. > However, there's nothing stopping Stripes from leveraging the existing > infrastructure even if it doesn't provide a way to programmatically set the > role and principle. If someone uses out of the box Form or BASIC security, > the @Role or whatever annotations will do the trick. IMHO, this is the best course of action for any framework (if you need it): only add to the authorization mechanism, and let the container handle authentication and propagate the principal. > I know we have our own custom login handler and our own realm for > GlassFish, using its programmatic login so it all works within the > framework of the JEE server. But its also GF specific, we'd have to port > that were we to go to another server. > > As far as implementing those modules and such in Stripes, that's not its > role, frankly. We use Stripes for login forms, and feed those inputs in to > our security mechanism. We use a Filter like every one else, but rely on > the Principals and Roles back on the EJB tier. Indeed: a filter at least allows you to override the roles and principles in the request. Given that Stripes (and many other frameworks as well) work more or less in the context of a servlet, overriding the principal and roles isn't even feasible. Regards, Oscar -- ,-_ Oscar Westra van Holthe - Kind http://www.xs4all.nl/~kindop/ /() ) (__ ( No trees were killed in the creation of this message. However, =/ () many electrons were terribly inconvenienced. signature.asc Description: Digital signature -- Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev___ Stripes-users mailing list Stripes-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stripes-users
