[Stripes-users] ActiveJDBC & Stripes

[Evan Leonard]

Hello all,

Its great to see the renewed interest in Stripes! I'm starting a new project on 
the framework and look forward to participating in the community.

In this first email I wanted to make the community aware of a project that I 
think it might be interested in.  While it seems that the community is fond of 
hibernate and stripersist, I've done an evaluation of the Java ActiveRecord 
implementations and found this one to be most interesting:

http://code.google.com/p/activejdbc/

In fact, I'm planning to use it for my relational data access. (I have some big 
document data which will go in CouchDB).

I'm planning to write an interceptor to help smooth the integration with 
Stripes, and will plan to share it with the community. If anyone else would be 
interested in this, please let me know. 

Best regards!
Evan Leonard

--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users

[Stripes-users] Add a new NodeType?

[Evan Leonard]

I'd like to try to add a new NodeType to 
net.sourceforge.stripes.util.bean.NodeType.  Is there anyway to do this without 
building my own stripes?

Evan


Graduate Student, Conflict Resolution, Denver University
Software Architect, Progress Software
c: 720-236-8892
p: 720-389-5755
e: evan.leon...@gmail.com


--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users

Re: [Stripes-users] Stripes Development and its Future... (long)

[Evan Leonard]

Barry, I like your idea of having stripes core and all the "shadow" libs In one 
repo. This would let the core maintain it's great focus but also allow a great 
community to be built around it. Think of what rails has done by allowing 
people to easily extend it with it's own plugins. Something around maven could 
be built to easily download and install plugins into a basic stripes project.  
I agree that what is needed is not a pre packaged full stack framework, but a 
loosely organized community of interdependent projects.  Spring isn't it 
either. Their new commercial intent has changed the tone of that community. 
Stripes is in and interesting position to take advantage of the opportunity 
that spring has created by disenfranchising a number of people. 

The news stripes website is a great start.  What can we do to organize the core 
and extensions in a similar way?

Evan



Sent from my iPad

On Sep 17, 2010, at 9:48 PM, Barry Davies  wrote:

> Freddy, Will, Ben, and all the regulars and new faces -
> 
> Long time, no see, had some time and a wild hair and decided to see what was 
> up on the Stripes boards.  I hope all is well with you and yours.  
> 
> Interesting to see some existential discussion and debate--always healthy to 
> see that come up periodically.  I got on the Stripes bandwagon pretty early 
> and my heart is still there.  But I haven't been able to completely commit to 
> Stripes enough to wholeheartedly evangelize it to our enterprise here as our 
> group's profile has risen and influence has grown.  The problem is that our 
> enterprise (huge IT org of 16k people with dev groups all over the world) is 
> starting to roll out enterprise infrastructure like (websphere) portal that 
> everyone is being expected to integrate with.  With all the massive emphasis 
> on portal, Stripes is almost a non-starter.  If only Stripes had a portlet 
> framework, the Spring apologists wouldn't have a leg to stand on.  As it 
> stands, I'm faced with the prospect of telling groups to use Stripes for 
> their web apps, but to use Spring's portlet framework and then to have to do 
> all their integrations on both fronts.  At that point, no one has patience to 
> continue listening, especially since SpringMVC is a reasonable option.  
> SpringMVC still stinks compared to Stripes, but it has come a long way.  The 
> frustrating thing is that SpringMVC has come far enough that those who only 
> really look at the surface similarities (either because that's how they roll, 
> or because they are Spring apologists looking for an excuse) see more 
> similarities than really exist.  Can you have an EntityTypeConverter (ala 
> Stripersist or my stack) in Spring? Yep, and it's almost as good, once you 
> decide on which of the 4 parallel/competing ways of creating a Spring analog 
> to Stripes TypeConverters that you are going to use.  Can you have 
> controllers with multiple handlers on them, driven by annotations?  Sure, but 
> you have to do your own cooperation between form and controller to get that 
> to work, and the annotation must be there--less convention-over-config.  And 
> even then, you need to have a new CommandBean for each multicontroller if you 
> really want to get close to the Stripes experience.  (Apologies if this info 
> is a touch out of date, we last dived deep into SpringMVC several months 
> ago.)  But again Spring has gotten closer.  Close enough that situations like 
> not having a portlet framework are now the deciding factor.  
> 
> I still don't think that extending Stripes out to a full-stack option is the 
> way to go.  The framework's uncanny ability to be easily integrated with all 
> manner of other frameworks for other areas of the stack I think is at least 
> partially due to the base design decision to favor as few other frameworks as 
> possible and stay neutral.  Way back when, the only other stack parts that 
> had "official" endorsement were o'reilly's file upload stuff and OGNL.  Tim 
> even found a way to give you a choice other than o'reilly and completely got 
> OGNL out of the picture.  It's a philosophy that works--leave trying to be 
> everything to everyone to Spring, and let them deal with the consequences and 
> related bloat/drag.  
> 
> I'd say, add support for the latest servlet api standards, perhaps finding 
> some crafty opportunities for enabling something Stripe-y.  Also, add a 
> portlet framework, so anyone in an org where an enterprise portal is required 
> integration has a nice Stripesy dev experience available to them.  And 
> perhaps, encourage /several/ shadow communities (such as informally exists 
> with Stripersist) to post links or maybe even host their codebases on the 
> official Stripes site.  As most have seen, Stripes is a framework that has 
> centered thus far on choice.  Let new users see several different full-stack 
> options to available to them via these shadow communities.  Let those 
> communities (and this proposed reside

Re: [Stripes-users] IMPORTANT:: Developing stripes (Future... Part DEUX)

[Evan Leonard]

Nikolaos,

Thank you for the thoughtful summary of the state of things. Since I just 
popped up here recently with my opinions, I thought it might be useful to 
introduce myself briefly, so people know where I'm coming from.

Starting in 2003, I began working at a startup in the SOAP/SOA world. We built 
a product using Struts 1.1 which was "the best thing at the time".  And I 
worked to overcoming its warts. I added flash scope, view models, and a number 
of other things by extending the core struts processor. I started down the road 
of creating some fancy-pants UI controls that would maintain their state 
seemlessly across request cycles using a viewstate concept like ASP.NET. (I 
abandoned this idea later, but want to give you an idea of the experiments I 
did working with struts).  By the time the app was done we had a 1400+ line 
struts.config file. I know the pains of struts well. 

Since then I've gone looking for something better. While still at that company 
we tried Grails, by bringing in the old app under a new grails app using the 
grails-struts plugin. Grails was, well, disappointing. You never can get away 
from the fact that groovy compiles to java before compiling to bytecode. The 
amount of reflection that happens to make a single method call is astounding. 
And then there's the magic stuff that appears in context somehow, and you have 
noway of knowing without digging through the documentation. Which brings me to 
rails. 

I've tried to prototype a number of things in Rails, and for all its buzz about 
being fast to develop, it never felt fast to me. The amount of time I spent 
going through documentation to understand what's in context was frustrating.  
I'm sure its super fast once you've spent a thousand hours learning it, but the 
ramp-up time is deceiving. There are a number of good things to learn from the 
design of the platform and the organization of community ecosystem however. (

(I won't bother covering my opinions about Springsource. Others have stated the 
situation there well already)

So, when recently I needed to select a new web framework and was pointed to 
Stripes by a former colleague and friend of mine I liked what I saw.  The 
ability to customize Stripes is great (for the most part), the way it can be 
made to work with other frameworks is great (for the most part).  But before 
committing to using it for the next year or more, I would really like to see an 
active community around it. Where there is a clear process for giving feedback, 
submitting patches, and generally contributing. This is the one area that is 
currently lacking. Yes, there are all the perception problems too that people 
have discussed. But if those are solved and there is still no clear way to 
contribute to the project, then the new interest won't turn into new activity.  

Stripes isn't perfect, I'm looking at integrating a different db layer other 
than hibernate, and I've found a few places I would like to be able to hook 
that are not currently hookable. I would like to be able to have my validations 
on my model classes and have them carried through to the view by Stripe's 
validation layer.  But I don't know who to talk with to make these things 
happen.  

I've seen other projects come to forking the code when the current owners of 
the project aren't able to continue or turn things over to others. That's 
usually the last resort. I certainly don't have the time to become a core 
maintainer on a project. But I do have time (and experience) to help a 
community organize itself around a good purpose. And it sounds like continuing 
the spirit of Stripes is a good purpose.

So with that, I hope to hear from the folks in the "core" currently.  I hope we 
can engage in some discussion about what the next steps are with respect to 
code ownership and the contribution process.

Thanks so much for all the work that been put into this project so far. 

All the best,
Evan Leonard




On Sep 18, 2010, at 10:09 AM, Nikolaos Giannopoulos wrote:

> Ben,
> 
> You have made it clear that you needed to get away from the code back in 
> June after having made a flurry of commits.  Everyone understands and 
> appreciates what you have done for Stripes as you have single handedly 
> maintained Stripes for quite some time (I assume since its beginnings 
> with Tim) and have been an incredible driving force IMO.
> 
> But the time of a single developer cobbling together code OR merely 
> accepting patches that are ready and tested from the community - but not 
> having the time to integrate them - must be over.  At some point in time 
> we need to stand aside to see a project grow otherwise we will - and not 
> to be dramatic - smother it and indeed it will die... .
> 
> There are developers like Evan, Nicolai, myself (down the road) and 
> others i

Re: [Stripes-users] IMPORTANT:: Developing stripes (Future... Part DEUX)

[Evan Leonard]

t; to the project, then respond to this email and commit to it. Let us know your 
> name, your history with Stripes, how you want to contribute, and any other 
> information that you think is relevant. If you can't contribute now but hope 
> to be able to in the future, then please wait until that time comes to speak 
> up. What I want is to know who we have in this group who can help breathe new 
> life into Stripes starting today. Let's hear it.
> 
> -Ben
> 
> On Sun, Sep 19, 2010 at 2:51 PM, Jeppe Cramon  wrote:
> Hi guys
> 
> I've been following this resurrection thread for a while and even though I 
> contributed some core parts to Stripes in the early days I haven't really had 
> the need for something like Stripes in a long time (for instance it lacks 
> proper REST and Comet style support).
> 
> IMO Stripes has faded because it has been too difficult to participate, add 
> patches and features.
> I like that the core of Stripes is kept tight, with focus on extensibility 
> and what's the core things for an Action based MVC framework.
> The low learning curve and the easy extensibility was what attracted me to 
> Stripes in the first place, but the lack of progress & new releases is 
> hurting Stripes.
> 
> Since this thread has appeared and have started a good discussion, I think 
> it's important to reach a consensus on where to take Stripes.
> IMO if this thread dies out with any clear forward action, then Stripes is 
> going to whither.
> 
> I agree with Rick, forking would be a good way to move forward.
> 
> My suggestion is to put Stripes on GitHub and allow people for Fork it like 
> crazy - see what the community can come up with and harvest the best ideas by 
> pulling from the best contributers.
> But IMO it's important that someone like Ben, Aaron or Freddy be the one(s) 
> maintaining the "official" Git Master and decide what gets pulled into the 
> official Stripes release.
> Perhaps someone will come by and create a fork that blows everyone away - 
> let's see what could happen ;)
> 
> /Jeppe
> 
> On Sun, 19 Sep 2010 20:27:21 +0200, Rick Grashel  wrote:
> 
> Evan,
> 
> Regarding your comment about forking the code being a last resort, I'm not 
> too sure about that.  In fact, I think forks are absolutely critical when an 
> OSS project is at a plateau.  Forking gets a really bad name, but I think it 
> is critical to a project's evolution.  Some of the most successful OSS 
> projects out there were a result of forks.
> 
> Especially when you look at a Linux distribution like Ubuntu.  Ubuntu really 
> was forked just to get more frequent and fresh releases.  Even today, it 
> still maintains the Debian base.  It has a couple of add-on features.  
> 
> I could easily see Stripes doing this.  All it really takes is a few people 
> who are willing to prioritize some goals (usually high-impact defects or 
> enhancement requests)... and then the fork is done.  
> 
> In my opinion, a fork is necessary with Stripes right now.  No release in 9 
> months.  A growing backlog of high-impact items.  A community that is 
> expressing serious concern.  Code that is committed or offered to be 
> committed without review or response.  Nobody who can really hands the keys 
> over.  
> 
> Sounds like the makings of a fork to me.  Someone just needs to step forward 
> and do it.  Personally, I would hope one of the original code contributors 
> would do it -- and then take a passive role.  But usually for political or 
> personal reasons, that isn't done.
> 
> -- Rick
> 
> 
> On Sat, Sep 18, 2010 at 7:02 PM, Evan Leonard  wrote:
> 
> Nikolaos,
> 
> Thank you for the thoughtful summary of the state of things. Since I just 
> popped up here recently with my opinions, I thought it might be useful to 
> introduce myself briefly, so people know where I'm coming from.
> 
> Starting in 2003, I began working at a startup in the SOAP/SOA world. We 
> built a product using Struts 1.1 which was "the best thing at the time".  And 
> I worked to overcoming its warts. I added flash scope, view models, and a 
> number of other things by extending the core struts processor. I started down 
> the road of creating some fancy-pants UI controls that would maintain their 
> state seemlessly across request cycles using a viewstate concept like 
> ASP.NET. (I abandoned this idea later, but want to give you an idea of the 
> experiments I did working with struts).  By the time the app was done we had 
> a 1400+ line struts.config file. I know the pains of struts well.
> 
> Since then I've gone looking for something better. While still at that 
> company we tried G

Re: [Stripes-users] IMPORTANT:: Developing stripes (Future... Part DEUX)

[Evan Leonard]

ntribute now but hope 
> to be able to in the future, then please wait until that time comes to speak 
> up. What I want is to know who we have in this group who can help breathe new 
> life into Stripes starting today. Let's hear it.
> 
> -Ben
> 
> 
> On Sun, Sep 19, 2010 at 2:51 PM, Jeppe Cramon  wrote:
> Hi guys
> 
> I've been following this resurrection thread for a while and even though I 
> contributed some core parts to Stripes in the early days I haven't really had 
> the need for something like Stripes in a long time (for instance it lacks 
> proper REST and Comet style support).
> 
> IMO Stripes has faded because it has been too difficult to participate, add 
> patches and features.
> I like that the core of Stripes is kept tight, with focus on extensibility 
> and what's the core things for an Action based MVC framework.
> The low learning curve and the easy extensibility was what attracted me to 
> Stripes in the first place, but the lack of progress & new releases is 
> hurting Stripes.
> 
> Since this thread has appeared and have started a good discussion, I think 
> it's important to reach a consensus on where to take Stripes.
> IMO if this thread dies out with any clear forward action, then Stripes is 
> going to whither.
> 
> I agree with Rick, forking would be a good way to move forward.
> 
> My suggestion is to put Stripes on GitHub and allow people for Fork it like 
> crazy - see what the community can come up with and harvest the best ideas by 
> pulling from the best contributers.
> But IMO it's important that someone like Ben, Aaron or Freddy be the one(s) 
> maintaining the "official" Git Master and decide what gets pulled into the 
> official Stripes release.
> Perhaps someone will come by and create a fork that blows everyone away - 
> let's see what could happen ;)
> 
> /Jeppe
> 
> On Sun, 19 Sep 2010 20:27:21 +0200, Rick Grashel  wrote:
> 
> Evan,
> 
> Regarding your comment about forking the code being a last resort, I'm not 
> too sure about that.  In fact, I think forks are absolutely critical when an 
> OSS project is at a plateau.  Forking gets a really bad name, but I think it 
> is critical to a project's evolution.  Some of the most successful OSS 
> projects out there were a result of forks.
> 
> Especially when you look at a Linux distribution like Ubuntu.  Ubuntu really 
> was forked just to get more frequent and fresh releases.  Even today, it 
> still maintains the Debian base.  It has a couple of add-on features.  
> 
> I could easily see Stripes doing this.  All it really takes is a few people 
> who are willing to prioritize some goals (usually high-impact defects or 
> enhancement requests)... and then the fork is done.  
> 
> In my opinion, a fork is necessary with Stripes right now.  No release in 9 
> months.  A growing backlog of high-impact items.  A community that is 
> expressing serious concern.  Code that is committed or offered to be 
> committed without review or response.  Nobody who can really hands the keys 
> over.  
> 
> Sounds like the makings of a fork to me.  Someone just needs to step forward 
> and do it.  Personally, I would hope one of the original code contributors 
> would do it -- and then take a passive role.  But usually for political or 
> personal reasons, that isn't done.
> 
> -- Rick
> 
> 
> On Sat, Sep 18, 2010 at 7:02 PM, Evan Leonard  wrote:
> 
> Nikolaos,
> 
> Thank you for the thoughtful summary of the state of things. Since I just 
> popped up here recently with my opinions, I thought it might be useful to 
> introduce myself briefly, so people know where I'm coming from.
> 
> Starting in 2003, I began working at a startup in the SOAP/SOA world. We 
> built a product using Struts 1.1 which was "the best thing at the time".  And 
> I worked to overcoming its warts. I added flash scope, view models, and a 
> number of other things by extending the core struts processor. I started down 
> the road of creating some fancy-pants UI controls that would maintain their 
> state seemlessly across request cycles using a viewstate concept like 
> ASP.NET. (I abandoned this idea later, but want to give you an idea of the 
> experiments I did working with struts).  By the time the app was done we had 
> a 1400+ line struts.config file. I know the pains of struts well.
> 
> Since then I've gone looking for something better. While still at that 
> company we tried Grails, by bringing in the old app under a new grails app 
> using the grails-struts plugin. Grails was, well, disappointing. You never 
> can get away from the fact that groovy compiles to java before compiling 

Re: [Stripes-users] IMPORTANT:: Developing stripes (Future... Part DEUX)

[Evan Leonard]

x27;ve reported is fixed. 
> Complaints about how something works or does not work are rarely accompanied 
> by a solution to the perceived problem.
> 
> My point is that talk is cheap. Who out there is really willing to dig in and 
> learn the Stripes code and dedicate a good chunk of time on a regular basis 
> to make it better? Who is willing to design a new web site? Who is willing to 
> review and correct and improve the documentation? Who is willing create and 
> maintain a Stripes-centric blog with regular articles?
> 
> If you are willing and able *right now* to start making a real contribution 
> to the project, then respond to this email and commit to it. Let us know your 
> name, your history with Stripes, how you want to contribute, and any other 
> information that you think is relevant. If you can't contribute now but hope 
> to be able to in the future, then please wait until that time comes to speak 
> up. What I want is to know who we have in this group who can help breathe new 
> life into Stripes starting today. Let's hear it.
> 
> -Ben
> 
> 
> On Sun, Sep 19, 2010 at 2:51 PM, Jeppe Cramon  wrote:
> Hi guys
> 
> I've been following this resurrection thread for a while and even though I 
> contributed some core parts to Stripes in the early days I haven't really had 
> the need for something like Stripes in a long time (for instance it lacks 
> proper REST and Comet style support).
> 
> IMO Stripes has faded because it has been too difficult to participate, add 
> patches and features.
> I like that the core of Stripes is kept tight, with focus on extensibility 
> and what's the core things for an Action based MVC framework.
> The low learning curve and the easy extensibility was what attracted me to 
> Stripes in the first place, but the lack of progress & new releases is 
> hurting Stripes.
> 
> Since this thread has appeared and have started a good discussion, I think 
> it's important to reach a consensus on where to take Stripes.
> IMO if this thread dies out with any clear forward action, then Stripes is 
> going to whither.
> 
> I agree with Rick, forking would be a good way to move forward.
> 
> My suggestion is to put Stripes on GitHub and allow people for Fork it like 
> crazy - see what the community can come up with and harvest the best ideas by 
> pulling from the best contributers.
> But IMO it's important that someone like Ben, Aaron or Freddy be the one(s) 
> maintaining the "official" Git Master and decide what gets pulled into the 
> official Stripes release.
> Perhaps someone will come by and create a fork that blows everyone away - 
> let's see what could happen ;)
> 
> /Jeppe
> 
> On Sun, 19 Sep 2010 20:27:21 +0200, Rick Grashel  wrote:
> 
> Evan,
> 
> Regarding your comment about forking the code being a last resort, I'm not 
> too sure about that.  In fact, I think forks are absolutely critical when an 
> OSS project is at a plateau.  Forking gets a really bad name, but I think it 
> is critical to a project's evolution.  Some of the most successful OSS 
> projects out there were a result of forks.
> 
> Especially when you look at a Linux distribution like Ubuntu.  Ubuntu really 
> was forked just to get more frequent and fresh releases.  Even today, it 
> still maintains the Debian base.  It has a couple of add-on features.  
> 
> I could easily see Stripes doing this.  All it really takes is a few people 
> who are willing to prioritize some goals (usually high-impact defects or 
> enhancement requests)... and then the fork is done.  
> 
> In my opinion, a fork is necessary with Stripes right now.  No release in 9 
> months.  A growing backlog of high-impact items.  A community that is 
> expressing serious concern.  Code that is committed or offered to be 
> committed without review or response.  Nobody who can really hands the keys 
> over.  
> 
> Sounds like the makings of a fork to me.  Someone just needs to step forward 
> and do it.  Personally, I would hope one of the original code contributors 
> would do it -- and then take a passive role.  But usually for political or 
> personal reasons, that isn't done.
> 
> -- Rick
> 
> 
> On Sat, Sep 18, 2010 at 7:02 PM, Evan Leonard  wrote:
> 
> Nikolaos,
> 
> Thank you for the thoughtful summary of the state of things. Since I just 
> popped up here recently with my opinions, I thought it might be useful to 
> introduce myself briefly, so people know where I'm coming from.
> 
> Starting in 2003, I began working at a startup in the SOAP/SOA world. We 
> built a product using Struts 1.1 which was "the best thing at the time".  And 
> I worked to ov

Re: [Stripes-users] IMPORTANT:: Developing stripes (Future... Part DEUX)

[Evan Leonard]

Freddy, I hear what you're saying.  I think I may have steering things in the 
wrong direction using words like "autocratic". I actually agree with what 
you're saying here, that there is a need for a lead. My question to Ed should 
probably be restated more simply as, "Would you tell us a little bit about how 
you would run things?"  That seems like a fair question to ask I think before 
"voting" or anything like that.  Not to mention that Ben still seems invested 
from his email this morning as well.  (Correct me if I'm wrong Ben).

Evan



On Sep 21, 2010, at 2:07 PM, Freddy Daoud wrote:

> Just my 2c, I hope this doesn't make things "worse" in terms of
> misunderstandings.
> 
>> I am not interested in taking a leading role, I am interested in
>> taking *the lead*.  Yes, I am aware of how this comes across and no I
>> will not apologize for it.  As I have stated before, what Stripes
>> needs most is leadership, plain and simple.
> 
> Personally, I was thrilled when I read Ed's comment. I did not read
> any "dictatorship" into it. All I read was that someone was willing
> to step up to the plate, stating it clearly, no two ways about it.
> I respect that very much.
> 
> I agree that Stripes needs leadership. Again, I don't see this as
> a synonym of "dictatorship", nor an opposite to "consensus". What I
> do see in this is someone, Ed, who has the skill and the will to
> assume the role of Stripes lead.
> 
> This does not mean to rule out other participants. But, IMHO, we
> do *need* someone that decides and makes things happen. Sure,
> it's all teamwork, but at the end of the day, when someone submits
> a patch, asks when the next release will be, asks if a feature
> belongs in the framework, and so on, there has to be *someone*
> who is *committed* to addressing and responding.
> 
> It's not a one-man show. But the problem with a team of
> contributors without someone who is the lead, is that for some
> issues, everyone looks at everyone else and no one responds.
> 
> This is why I applaud Ed's statement that he is willing to take
> on this responsibility for Stripes.
> 
> First on the list, I think, is to plan out the release of
> Stripes 1.5.x and Stripes 1.6, and work from there.
> 
> Again, just my 2c. I hope I didn't create more than resolve
> "conflict", and please also know that I don't mean to speak
> for you, Ed. I'm just expressing what I read into it, and I
> hope it rings true with your intentions. I'm pretty sure you
> didn't mean that you would become a dictator, nor that you
> wouldn't encourage teamwork and healthy discussions about
> Stripes' future.
> 
> Personally, I say thanks, Ed. You have my vote.
> 
> Cheers,
> Freddy
> 
> --
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> ___
> Stripes-users mailing list
> Stripes-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/stripes-users


--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users

Re: [Stripes-users] database connection

[Evan Leonard]

I think he meant "Load Balancer" by LB


On Sep 22, 2010, at 3:37 PM, Joaquin Valdez wrote:

> Thank you Nikolaos for the great information and response!
> 
> I will get those exceptions and get them to you in a bit.
> 
> When I began using c3po and began to notice the oddities.  I began to  
> look around and see what else is out there.  I too found bonecp and  
> will investigate using that.
> 
> What is an LB ?
> 
> Thanks!
> Joaquin
> 
> 
> 
> On Sep 22, 2010, at 1:33 PM, Nikolaos Giannopoulos wrote:
> 
>> Joaquin,
>> 
>> You really need to get a copy of those Exceptions... broken pipe on a
>> web / app server typically is quite normal as it can be as simple as
>> someone hitting the stop or the refresh button on their web browser
>> while the server was trying to process a request.
>> 
>> Also it may be a consequence of the fact that your application is  
>> losing
>> database connectivity... broken pages... people hitting refresh
>> repeatedly... etc... .  So if this is as frequent as you state then
>> simply put together some of the stack traces and send that out.
>> 
>> c3p0 has a number of settings that set out how many times it will  
>> retry,
>> the interval it will wait between retries and / or how long it will
>> retry before giving up, etc... and if IIRC some settings had to go  
>> in a
>> c3p0 properties file and NOT just in the persistence.xml (in fact in  
>> the
>> XML file they would be ignored).  Just google things and you should  
>> find
>> some pretty useful docs... .  I imagine this is your config problem
>> though this doesn't address why your connections are breaking in the  
>> 1st
>> place.
>> 
>> BTW is there a hardware LB in the picture?  Those are notorious for
>> chopping connections that remain idle for what is pretty much standard
>> at around 16 seconds.  This isn't an issue under low load as  
>> connections
>> simply get recycled at a high frequency... but get yourself up to
>> 10K-30K connections and voila log jam... the pool spends more time
>> trying to create connections than it can use and you end up with
>> something like 5000 TCP connections on the server.  Not fun indeed.   
>> But
>> ever so common on high end systems.
>> 
>> Lastly, as far as Connection Pool is concerned I have to say I have  
>> done
>> a fair amount of research and am quite disappointed that either  
>> projects
>> have been abandoned or not updated despite known issues...  IIRC there
>> were some synchronization bugs in c3p0 that can come up... so for  
>> now we
>> ended up looking at BoneCP and use that for now although I'm not sure
>> how well it can recover broken connections.
>> 
>> Oh... and I almost forgot... 2 reasons I imagine that Connection  
>> Pooling
>> projects have been more and more stale are b/c i) App Servers these  
>> days
>> have built in connection pooling functionality that should be pretty
>> good and ii) some consider them finished and sufficient for their
>> purposes... despite the growing list of possibly "rarer" issues,  
>> RFE's,
>> etc...
>> 
>> --Nikolaos
>> 
>> 
>> 
>> 
>> Joaquin Valdez wrote:
>>> Hello!
>>> 
>>> I am wondering what the proper way of handling a database connection
>>> pool when it looses connection to the database.  My application will
>>> run fine for 2 weeks then it will start throwing broken pipe errors.
>>> I don't have the exact error but that is what the error says.  I  
>>> use a
>>> postgres database and the c3po hibernate connection pool.  How do I
>>> ensure connectivity is maintained?
>>> 
>>> Maybe a database connection interceptor?  Just an idea.
>>> 
>>> Here is my persistence.xml file:
>>> 
>>> 
>>> http://java.sun.com/xml/ns/
>>> persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>>> xsi:schemaLocation="http://java.sun.com/xml/ns/persistence 
>>> http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd
>>> ">
>>>>> type="RESOURCE_LOCAL">
>>>org.hibernate.ejb.HibernatePersistence
>>>false
>>>
>>>>> value="org.hibernate.cache.NoCacheProvider"/>
>>>>> value="class"/>
>>>>> value="org.hibernate.dialect.PostgreSQLDialect"/>
>>>
>>>  
>>>  
>>>  
>>>  
>>>
>>>
>>>  
>>>
>>>
>>>
>>>
>>>
>>>>> value="org.postgresql.Driver"/>
>>> 
>>>  
>>> 
>>>>> value=""/>
>>>>> value=""/>
>>>>> value="jdbc:postgresql://localhost/postgres"/>
>>> 
>>> 
>>>  
>>> 
>>> 
>>>
>>> 
>>> 
>>> 
>>> 
>>>
>>>
>>>
>>> 
>>> 
>>> 
>>> 
>>> Thanks!
>>> Joaquin
>>> 
>>> 
>>> 
>>> --
>>> Start uncovering the many advantages of virtual appliances
>>> and start using them to simplify application deployment and
>>> accelerate your shift to cloud computing.
>>> http://p.sf.net/sfu/

Re: [Stripes-users] [Stripes-dev] Finally, 1.5.3 available from maven central !

[Evan Leonard]

Yes, thank you!


On Sep 24, 2010, at 7:33 AM, Ben Gunter wrote:

> I don't even use Maven, but thank you, thank you, thank you, thank you, thank 
> you!
> 
> On Fri, Sep 24, 2010 at 9:29 AM, VANKEISBELCK Remi  wrote:
> Hi there,
> 
> Here we are :
> http://repo1.maven.org/maven2/net/sourceforge/stripes/stripes/1.5.3/
> :)
> 
> Cheers
> 
> Remi 
> 
> PS : I retire all the bad words I said about Sonatype the other day on IRC. 
> Their stuff works fine :P
> --
> Nokia and AT&T present the 2010 Calling All Innovators-North America contest
> Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
> http://p.sf.net/sfu/nokia-dev2dev___
> Stripes-development mailing list
> stripes-developm...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/stripes-development

--
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users

Re: [Stripes-users] IMPORTANT:: Developing stripes (Future... Part DEUX)

[Evan Leonard]

Ed, thank you. This is what I was trying to ask for earlier. I'm glad Ben was 
able to clarify to question.

Evan

On Sep 24, 2010, at 8:29 AM, Edward Smith wrote:

> Freddy:  First of all, *thank you* for clarifying what I meant from my terse 
> comments.  Sometimes to get a point across, I have to lay it out there 
> cut-and-dry.  Yes, everything said rings true with my intentions.  Hence you 
> may speak for me anytime Freddy.
> Ben:  Very glad to get your input and will address it as clearly and 
> respectfully as I can:
> The "evasive"-ness of my opening email ties back to "to the rest of us you 
> just sort of came out of nowhere to claim a leadership role".  With that in 
> mind:
> - "you meant you are planning to *use* Stripes in a project and you can't 
> disclose the nature of that project"  Precisely.  Basically was some idle 
> chit-chat to go along with 'Uh, yeah, I'd like to...'
> - "Maybe when you didn't speak of your qualifications, it was out of 
> humility"  Bingo.  That along with the breadth and depth of experiences I've 
> had in my career, I honestly wouldn't know where to begin.  After being 
> around Java and web applications for 13, going on 14, years now there's a lot 
> I've seen and done.  Anyone else on here remember the days before JSPs when 
> you had to put HTML into the Servlet?  Good times!
>  
> - "maybe that was an attempt to keep from sinking further into the quicksand" 
>  Right again.  When I perform a *leadership action* by making a stand on 
> something I believe in and it somehow turns into me seeking an autocratic 
> dictatorship, I'm out.  Stripes has no king, Stripes needs no king.  Stripes 
> does need a *steward* to evolve any further than where it stands today.
>  
> - "I like that you got a +1 from Melinda, who has been active on the mailing 
> list for years." and "you don't seem to have been very active on the mailing 
> list or IRC" are related so I will answer both right now.  When I became 
> Melinda's lead, she had very little experience developing with Java let alone 
> Enterprise Java Web applications.  As an example of my leadership style, when 
> Melinda would first come to me with Stripes questions, I would encourage her 
> to be the one to reach out to the Stripes community and find the answer.  
> Delegating that responsibility was one of the ways to let her grow personally 
> and professionally.
>  
> As far as my Stripes community activity goes, yes it has been more behind the 
> scenes.  In 2006, Stripes easily won the web framework architectural review I 
> conducted over Struts, JSF, Spring MVC, Tapestry, etc.  I wrote a proposal 
> for the JavaOne Call For Papers a few years ago with the goal being to 
> present a Technical Session on the Stripes Framework at JavaOne.  I was going 
> to attend anyway, might as well spread the word on Stripes while I was there. 
>  The proposal was not accepted.  Within four months of being at my current 
> job, I *proactively* wrote up an Application Architecture Proposal document 
> almost entirely centered around using Stripes instead of Struts 1.2.x which 
> is what they have been using since 2002.  That has started high-level 
> discussions about rearchitecting the application but I am quite concerned 
> about Spring MVC winning the web framework battle over Stripes because nobody 
> I work with has ever heard of Stripes.
> - "What people are asking of you is just a little sales pitch. We want to 
> know what you think the project needs and what you plan to do to provide 
> that."  This is million dollar question.  I don't have a million dollar 
> answer, but I'll give it a go:
> At this moment, I am a *former* Stripes user.  Having such a positive 
> experience as a Stripes user in the past, I would like nothing more than to 
> be a happy Stripes user *in the future*.  Based on that premise, there are a 
> few reasons why I stepped up to the plate:
> 1. The Stripes Elders are happy with the way Stripes is today, yet recently 
> several users have been on the mailing list giving the outside community 
> point of view.  From the outside looking in, Stripes looks outdated, falling 
> behind the times, and for a lack of a better word 'fossilizing'.
>  
> 2. As you said Ben, you no longer have the time or energy to provide proper 
> leadership on the project.  We all see that and a couple new faces have 
> spoken up, taken some action, and tried to fill that leadership void.  The 
> effort is commended, however taking the leadership role and dividing it up 
> piecemeal just won't work.  Who is the Stripes community supposed to go to 
> when they have an issue, an idea or suggestion, or even want to contribute?  
> And who is responsible for taking all of that community input and energy and 
> make something happen?  Right now I can't tell you who because I have no idea.
>  
> 3. By 'throwing my hat into the ring' I just wanted to start a discussion on 
> the future leadership of Stripes, not a Civil War or

[Stripes-users] Trouble with MockServletContext & Spring

[Evan Leonard]

Hi all,

I'm trying to get the spring context loading in my tests using the examples 
from Freddy's book. Basically I've got this in my test:

mockServletContext.addInitParameter("contextConfigLocation", 
"/WEB-INF/applicationContext.xml");
ContextLoaderListener springContextLoader = new ContextLoaderListener();
springContextLoader.contextInitialized(new 
ServletContextEvent(mockServletContext));

And I'm getting a FileNotFound down in spring's XmlBeanDefinitionReader.  At 
first I thought this would be as simple as changing my working directory to be 
the maven target/myapp directory, since that's the parent of WEB-INF at 
runtime, but that did change the behavior.

Any other ideas? Seems like its probably something pretty basic, and its just 
too late for me to see it...

Thanks!
Evan



--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users

Re: [Stripes-users] Trouble with MockServletContext & Spring

[Evan Leonard]

One other detail... when I remove this code to skip spring for now I do get 
these log statements pointing to the correct directories:

568 [main] INFO net.sourceforge.stripes.util.ResolverUtil - Scanning for 
classes in 
[/Users/evan/.m2/repository/net/sourceforge/stripes/stripes/1.5/stripes-1.5.jar]
 matching criteria: is assignable to MultipartWrapperFactory
595 [main] INFO net.sourceforge.stripes.util.ResolverUtil - Scanning for 
classes in 
[/Users/evan/dev/kono/kono-web/target/classes/com/kono/stripes/activejdbc] 
matching criteria: is assignable to MultipartWrapperFactory
599 [main] INFO net.sourceforge.stripes.util.ResolverUtil - Scanning for 
classes in 
[/Users/evan/.m2/repository/net/sourceforge/stripes/stripes/1.5/stripes-1.5.jar]
 matching criteria: is assignable to MultipartWrapper
626 [main] INFO net.sourceforge.stripes.util.ResolverUtil - Scanning for 
classes in 
[/Users/evan/dev/kono/kono-web/target/classes/com/kono/stripes/activejdbc] 
matching criteria: is assignable to MultipartWrapper

So many things are loading correctly... just not my applicationContext.xml!

Evan


On Sep 26, 2010, at 1:42 AM, Evan Leonard wrote:

>   
> Hi all,
> 
> I'm trying to get the spring context loading in my tests using the examples 
> from Freddy's book. Basically I've got this in my test:
> 
>mockServletContext.addInitParameter("contextConfigLocation", 
> "/WEB-INF/applicationContext.xml");
>ContextLoaderListener springContextLoader = new 
> ContextLoaderListener();
>springContextLoader.contextInitialized(new 
> ServletContextEvent(mockServletContext));
> 
> And I'm getting a FileNotFound down in spring's XmlBeanDefinitionReader.  At 
> first I thought this would be as simple as changing my working directory to 
> be the maven target/myapp directory, since that's the parent of WEB-INF at 
> runtime, but that did change the behavior.
> 
> Any other ideas? Seems like its probably something pretty basic, and its just 
> too late for me to see it...
> 
> Thanks!
> Evan
> 
> 


--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users

[Stripes-users] StripesSpec - Containerless view testing

[Evan Leonard]

Hey Guys,

I've been working on a little project for fun integrating the Stripes mock 
objects and HtmlUnit so that I can test my views without a container or 
browser. I'm using the new selenium 2/WebDriver interfaces, so conceivably 
these tests could be converted to run with another WebDriver class also.

Have a look at the test class below. The code is thrown together at the moment, 
but if this is something that others are interested in, we might be able to 
work on extracting it and making it usable outside my environment. Or maybe 
this is just a bad idea to start with all together! Either way, i'm curious to 
hear your thoughts.


--- SignupSpec.java 
---
package com.kono.action;

import com.kono.stripes.KonoWebSpec;
import net.sourceforge.stripes.validation.ValidationErrors;
import org.openqa.selenium.WebElement;
import org.testng.annotations.BeforeTest;
import org.testng.annotations.Test;

import static javalite.test.jspec.JSpec.the;

public class SignupSpec extends KonoWebSpec
{

@BeforeTest
public void givenUserIsOnSignupPage()
{
get(SignupAction.class);
}


@Test
public void whenSubmittingNoData() throws Exception
{
WebElement submitButton = findElementByName("createAccount");
the(submitButton).shouldNotBeNull();

submitButton.click();

ValidationErrors errors = validationErrors();
the(errors.size()).shouldEqual(3);
}

}
--- End Class  
---

What this class does is actually make a request through Stripes to the default 
action on the 
SignupAction bean class. It then integrates the view (a freemarker template in 
my case) into
the context to be available in any following WebDriver commands.  

When "submitButton.click()" is called, another request is made back through 
Stripes which
in this case fails validation. The sourcePage is then integrated into the 
context, including the 
error messages in the html.

Notice how you can mix assertion on both the DOM and the bean class in one 
location. (Is this a good idea?)
Also notice that the test class extends my own base class. That base class sets 
Stripes up for my
test environment. Unfortunately it duplicates a lot of things that are declared 
elsewhere, like in
my web.xml right now. So it sure could use some improvement. Here is what that 
looks like
right now

--- KonoStripesSpec.java 
---
package com.kono.stripes;

import com.kono.spring.KonoServletContextListener;
import net.sourceforge.stripes.controller.StripesFilter;
import org.springframework.web.context.ContextLoader;
import org.springframework.web.context.ContextLoaderListener;
import org.testng.annotations.AfterSuite;
import org.testng.annotations.BeforeSuite;

import javax.servlet.ServletContextEvent;
import java.util.HashMap;
import java.util.Map;

public class KonoWebSpec extends StripesSpec
{

ContextLoaderListener springContextLoader;

static
{
StripesSpecServletContext context = 
StripesSpec.createContext("kono-web");

//Spring Config
context.addInitParameter(ContextLoader.CONFIG_LOCATION_PARAM, 
"classpath:applicationContext.xml");

//JSTL config

context.addInitParameter("javax.servlet.jsp.jstl.fmt.localizationContext", 
"translations/text");

//Stripes Filter
Map params = new HashMap();
params.put("ActionResolver.Packages", "com.kono.action");
params.put("Extension.Packages", 
"net.sourceforge.stripes.integration.spring," +
 "com.kono.stripes.activejdbc");

params.put("ActionResolver.Class","com.kono.stripes.KonoActionResolver");
params.put("ActionBeanContext.Class", 
"com.kono.stripes.KonoActionBeanContext");
params.put("ExceptionHandler.Class", 
"com.kono.stripes.KonoExceptionHandler");

params.put("LocalizationBundleFactory.FieldNameBundle","translations/fieldLabels");

params.put("LocalizationBundleFactory.ErrorMessageBundle","translations/errors");
context.addFilter(StripesFilter.class, "StripesFilter", params);
}

@BeforeSuite
public void setupContext() throws Exception
{
springContextLoader = new KonoServletContextListener();
springContextLoader.contextInitialized(new 
ServletContextEvent(servletContext()));
}


@AfterSuite
public void teardownContext()
{
springContextLoader.contextDestroyed(new 
ServletContextEvent(servletContext()));
}
}
--- End Class  
---

To use this in your environment you'd have to create a base class like this one 
to match your setup.
The base class here, Strip

Re: [Stripes-users] Stripes Development and its Future... (long)

[Evan Leonard]

 +1.  Though it will take one of us being dissatisfied *enough* to implement 
this ourselves :-)


On Oct 2, 2010, at 9:05 PM, Simon wrote:

>> In other words, in Stripes you'd have
>> 
>> private User user;
>> 
>> /* getters and setters */
>> 
>> public Resolution save() {
>>  // do something with user
>> }
>> 
>> In Spring MVC you'd have
>> 
>> public void save(User user) {
>>  // do something with user
>> }
>> 
>> The "do something"s in both Stripes action beans and Spring controllers are
>> best left to injected helpers, daos, and so on, keeping the action/controller
>> classes simple.
>> 
>> So, in that respect, I'm not sure that using local variables leads to more
>> complex procedural code, if you keep things simple in controllers.
> 
> The main drawback to the Stripes approach is that if you have multiple
> handlers on a single action it becomes ambiguous which bean properties
> are inputs to each action.  When they are arguments to the handler
> method it is super clear what applies where.   I wouldn't mind
> sometimes if Stripes supported either approach - why not just look for
> any method that returns Resolution and then if there are parameters,
> try to bind them, if you can?   (yes, you probably need annotations to
> tell you the name to bind on, but I can live with that)
> 
> Cheers,
> 
> Simon
> 
> --
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> ___
> Stripes-users mailing list
> Stripes-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/stripes-users


--
Virtualization is moving to the mainstream and overtaking non-virtualized
environment for deploying applications. Does it make network security 
easier or more difficult to achieve? Read this whitepaper to separate the 
two and get a better understanding.
http://p.sf.net/sfu/hp-phase2-d2d
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users

Re: [Stripes-users] Stripes Development and its Future... (long)

[Evan Leonard]

Looks like some folks have gone to great lengths to add access to parameter 
names, eg: http://paranamer.codehaus.org/


On Oct 5, 2010, at 6:48 AM, Poitras Christian wrote:

> It's a problem that we faced in MyBatis when dealing with multiple 
> parameters. We went with the annotation approach.
> I guess there are many workarounds for that and Spring is probably using one. 
> Debug seems like a good workaround.
> 
> Christian
> 
> -Message d'origine-
> De : Freddy Daoud [mailto:xf2...@fastmail.fm] 
> Envoyé : October-05-10 8:40 AM
> À : Stripes Users List
> Objet : Re: [Stripes-users] Stripes Development and its Future... (long)
> 
> Are you sure? I think that if you compile with debug info turned
> on, and your request parameters are named param1 and param2,
> they will be bound correctly without the need for the annotations.
> 
> Or is that what you meant by "you will need the source code"?
> 
> Cheers,
> Freddy
> 
> On Tue, 5 Oct 2010 08:36:43 -0400, "Poitras Christian"
>  said:
>> A problem with the Spring approach is that parameter names are not
>> accessible by reflection.
>> The consequence is that if you have method like
>> public void substract(int param1, int param2)
>> It will be difficult to pass the parameters in the right order. You will
>> need either the source code to find the parameter names or an annotation
>> like
>> public void substract(@Param("param1") int param1, @Param("param2") int
>> param2)
>> 
>> Stripes is not affected by that problem.
>> 
>> Christian
>> 
>> -Message d'origine-
>> De : Evan Leonard [mailto:evan.leon...@gmail.com] 
>> Envoyé : October-04-10 4:59 PM
>> À : Stripes Users List
>> Objet : Re: [Stripes-users] Stripes Development and its Future... (long)
>> 
>> +1.  Though it will take one of us being dissatisfied *enough* to
>> implement this ourselves :-)
>> 
>> 
>> On Oct 2, 2010, at 9:05 PM, Simon wrote:
>> 
>>>> In other words, in Stripes you'd have
>>>> 
>>>> private User user;
>>>> 
>>>> /* getters and setters */
>>>> 
>>>> public Resolution save() {
>>>> // do something with user
>>>> }
>>>> 
>>>> In Spring MVC you'd have
>>>> 
>>>> public void save(User user) {
>>>> // do something with user
>>>> }
>>>> 
>>>> The "do something"s in both Stripes action beans and Spring controllers are
>>>> best left to injected helpers, daos, and so on, keeping the 
>>>> action/controller
>>>> classes simple.
>>>> 
>>>> So, in that respect, I'm not sure that using local variables leads to more
>>>> complex procedural code, if you keep things simple in controllers.
>>> 
>>> The main drawback to the Stripes approach is that if you have multiple
>>> handlers on a single action it becomes ambiguous which bean properties
>>> are inputs to each action.  When they are arguments to the handler
>>> method it is super clear what applies where.   I wouldn't mind
>>> sometimes if Stripes supported either approach - why not just look for
>>> any method that returns Resolution and then if there are parameters,
>>> try to bind them, if you can?   (yes, you probably need annotations to
>>> tell you the name to bind on, but I can live with that)
>>> 
>>> Cheers,
>>> 
>>> Simon
>>> 
>>> --
>>> Start uncovering the many advantages of virtual appliances
>>> and start using them to simplify application deployment and
>>> accelerate your shift to cloud computing.
>>> http://p.sf.net/sfu/novell-sfdev2dev
>>> ___
>>> Stripes-users mailing list
>>> Stripes-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/stripes-users
>> 
>> 
>> --
>> Virtualization is moving to the mainstream and overtaking non-virtualized
>> environment for deploying applications. Does it make network security 
>> easier or more difficult to achieve? Read this whitepaper to separate the 
>> two and get a better understanding.
>> http://p.sf.net/sfu/hp-phase2-d2d
>> ___
>> Stripes-users mailing list
>

Re: [Stripes-users] Stripes Development and its Future... (long)

[Evan Leonard]

Here's an interesting approach from the waffle framework. It uses annotations, 
but lists all the parameter names in a single annotation.

@ActionMethod(parameters = {"firstNumber", "secondNumber"})  

Evan


On Oct 5, 2010, at 6:48 AM, Poitras Christian wrote:

> It's a problem that we faced in MyBatis when dealing with multiple 
> parameters. We went with the annotation approach.
> I guess there are many workarounds for that and Spring is probably using one. 
> Debug seems like a good workaround.
> 
> Christian
> 
> -Message d'origine-
> De : Freddy Daoud [mailto:xf2...@fastmail.fm] 
> Envoyé : October-05-10 8:40 AM
> À : Stripes Users List
> Objet : Re: [Stripes-users] Stripes Development and its Future... (long)
> 
> Are you sure? I think that if you compile with debug info turned
> on, and your request parameters are named param1 and param2,
> they will be bound correctly without the need for the annotations.
> 
> Or is that what you meant by "you will need the source code"?
> 
> Cheers,
> Freddy
> 
> On Tue, 5 Oct 2010 08:36:43 -0400, "Poitras Christian"
>  said:
>> A problem with the Spring approach is that parameter names are not
>> accessible by reflection.
>> The consequence is that if you have method like
>> public void substract(int param1, int param2)
>> It will be difficult to pass the parameters in the right order. You will
>> need either the source code to find the parameter names or an annotation
>> like
>> public void substract(@Param("param1") int param1, @Param("param2") int
>> param2)
>> 
>> Stripes is not affected by that problem.
>> 
>> Christian
>> 
>> -Message d'origine-
>> De : Evan Leonard [mailto:evan.leon...@gmail.com] 
>> Envoyé : October-04-10 4:59 PM
>> À : Stripes Users List
>> Objet : Re: [Stripes-users] Stripes Development and its Future... (long)
>> 
>> +1.  Though it will take one of us being dissatisfied *enough* to
>> implement this ourselves :-)
>> 
>> 
>> On Oct 2, 2010, at 9:05 PM, Simon wrote:
>> 
>>>> In other words, in Stripes you'd have
>>>> 
>>>> private User user;
>>>> 
>>>> /* getters and setters */
>>>> 
>>>> public Resolution save() {
>>>> // do something with user
>>>> }
>>>> 
>>>> In Spring MVC you'd have
>>>> 
>>>> public void save(User user) {
>>>> // do something with user
>>>> }
>>>> 
>>>> The "do something"s in both Stripes action beans and Spring controllers are
>>>> best left to injected helpers, daos, and so on, keeping the 
>>>> action/controller
>>>> classes simple.
>>>> 
>>>> So, in that respect, I'm not sure that using local variables leads to more
>>>> complex procedural code, if you keep things simple in controllers.
>>> 
>>> The main drawback to the Stripes approach is that if you have multiple
>>> handlers on a single action it becomes ambiguous which bean properties
>>> are inputs to each action.  When they are arguments to the handler
>>> method it is super clear what applies where.   I wouldn't mind
>>> sometimes if Stripes supported either approach - why not just look for
>>> any method that returns Resolution and then if there are parameters,
>>> try to bind them, if you can?   (yes, you probably need annotations to
>>> tell you the name to bind on, but I can live with that)
>>> 
>>> Cheers,
>>> 
>>> Simon
>>> 
>>> --
>>> Start uncovering the many advantages of virtual appliances
>>> and start using them to simplify application deployment and
>>> accelerate your shift to cloud computing.
>>> http://p.sf.net/sfu/novell-sfdev2dev
>>> ___
>>> Stripes-users mailing list
>>> Stripes-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/stripes-users
>> 
>> 
>> --
>> Virtualization is moving to the mainstream and overtaking non-virtualized
>> environment for deploying applications. Does it make network security 
>> easier or more difficult to achieve? Read this whitepaper to separate the 
>> two and get a better understanding.
>> http://p.sf.net/sfu

Re: [Stripes-users] Associating Parameters to Specific Actions

[Evan Leonard]

Certainly!  

I started doing a little prototyping with this today while waiting for another 
build to finish. I'm trying the approach of having one annotation on the method 
like this:

@ParamBinding({"aString", "aNumber"})  
public Resolution myAction(String aString, int aNumber) { ... }

The question I'm currently thinking about is whether to add to the 
implementation of DefaultActionBeanPropertyBinder or whether there should be 
second type of binder, something like this:

public interface ActionHandlerParameterBinder extends ConfigurableComponent  {
ValidationErrors bind(final Method handler, ActionBean bean, 
ActionBeanContext context, boolean validate);
}


Thoughts?

Evan


On Oct 5, 2010, at 1:19 PM, Nikolaos Giannopoulos wrote:

> Evan / Christian / Remi et al.
> 
> This thread is very interesting and I am enjoying it... and hope it 
> continues...
> However, can we rename this thread to something more aligned to the 
> discussion?
> 
> If no one minds I have taken the liberty to rename it to the above ;-)
> 
> Regards,
> 
> --Nikolaos
> 
> 
> 
> 
> Evan Leonard wrote:
>> Here's an interesting approach from the waffle framework. It uses 
>> annotations, but lists all the parameter names in a single annotation.
>> 
>> @ActionMethod(parameters = {"firstNumber", "secondNumber"})  
>> 
>> Evan
>> 
>> 
>> On Oct 5, 2010, at 6:48 AM, Poitras Christian wrote:
>> 
>> 
>>> It's a problem that we faced in MyBatis when dealing with multiple 
>>> parameters. We went with the annotation approach.
>>> I guess there are many workarounds for that and Spring is probably using 
>>> one. Debug seems like a good workaround.
>>> 
>>> Christian
>>> 
>>> -Message d'origine-
>>> De : Freddy Daoud [mailto:xf2...@fastmail.fm] 
>>> Envoyé : October-05-10 8:40 AM
>>> À : Stripes Users List
>>> Objet : Re: [Stripes-users] Stripes Development and its Future... (long)
>>> 
>>> Are you sure? I think that if you compile with debug info turned
>>> on, and your request parameters are named param1 and param2,
>>> they will be bound correctly without the need for the annotations.
>>> 
>>> Or is that what you meant by "you will need the source code"?
>>> 
>>> Cheers,
>>> Freddy
>>> 
>>> On Tue, 5 Oct 2010 08:36:43 -0400, "Poitras Christian"
>>>  said:
>>> 
>>>> A problem with the Spring approach is that parameter names are not
>>>> accessible by reflection.
>>>> The consequence is that if you have method like
>>>> public void substract(int param1, int param2)
>>>> It will be difficult to pass the parameters in the right order. You will
>>>> need either the source code to find the parameter names or an annotation
>>>> like
>>>> public void substract(@Param("param1") int param1, @Param("param2") int
>>>> param2)
>>>> 
>>>> Stripes is not affected by that problem.
>>>> 
>>>> Christian
>>>> 
>>>> -Message d'origine-
>>>> De : Evan Leonard [mailto:evan.leon...@gmail.com] 
>>>> Envoyé : October-04-10 4:59 PM
>>>> À : Stripes Users List
>>>> Objet : Re: [Stripes-users] Stripes Development and its Future... (long)
>>>> 
>>>> +1.  Though it will take one of us being dissatisfied *enough* to
>>>> implement this ourselves :-)
>>>> 
>>>> 
>>>> On Oct 2, 2010, at 9:05 PM, Simon wrote:
>>>> 
>>>> 
>>>>>> In other words, in Stripes you'd have
>>>>>> 
>>>>>> private User user;
>>>>>> 
>>>>>> /* getters and setters */
>>>>>> 
>>>>>> public Resolution save() {
>>>>>> // do something with user
>>>>>> }
>>>>>> 
>>>>>> In Spring MVC you'd have
>>>>>> 
>>>>>> public void save(User user) {
>>>>>> // do something with user
>>>>>> }
>>>>>> 
>>>>>> The "do something"s in both Stripes action beans and Spring controllers 
>>>>>> are
>>>>>> best left to injected helpers, daos, and so on, keeping the 
>>>>>> action/controller
>>>>>> classes simple.
>>>>>> 
>>

Re: [Stripes-users] Associating Parameters to Specific Actions

[Evan Leonard]

I was thinking it would be possible to use both. Either by adding a second type 
of binder to the configuration, so they both run, or potentially by subclassing 
the existing binder to overlay the functionality.


On Oct 5, 2010, at 2:36 PM, Poitras Christian wrote:

> The downside of using 2 binders is that it's difficult to mix both approach.
> 
> Still, it would seem bizarre to have both approach in the same program...
> 
> -Message d'origine-
> De : Evan Leonard [mailto:evan.leon...@gmail.com] 
> Envoyé : October-05-10 3:31 PM
> À : nikol...@brightminds.org; Stripes Users List
> Objet : Re: [Stripes-users] Associating Parameters to Specific Actions
> 
> 
> Certainly!  
> 
> I started doing a little prototyping with this today while waiting for 
> another build to finish. I'm trying the approach of having one annotation on 
> the method like this:
> 
> @ParamBinding({"aString", "aNumber"})  
> public Resolution myAction(String aString, int aNumber) { ... }
> 
> The question I'm currently thinking about is whether to add to the 
> implementation of DefaultActionBeanPropertyBinder or whether there should be 
> second type of binder, something like this:
> 
> public interface ActionHandlerParameterBinder extends ConfigurableComponent  {
>ValidationErrors bind(final Method handler, ActionBean bean, 
> ActionBeanContext context, boolean validate);
> }
> 
> 
> Thoughts?
> 
> Evan
> 
> 
> On Oct 5, 2010, at 1:19 PM, Nikolaos Giannopoulos wrote:
> 
>> Evan / Christian / Remi et al.
>> 
>> This thread is very interesting and I am enjoying it... and hope it 
>> continues...
>> However, can we rename this thread to something more aligned to the 
>> discussion?
>> 
>> If no one minds I have taken the liberty to rename it to the above ;-)
>> 
>> Regards,
>> 
>> --Nikolaos
>> 
>> 
>> 
>> 
>> Evan Leonard wrote:
>>> Here's an interesting approach from the waffle framework. It uses 
>>> annotations, but lists all the parameter names in a single annotation.
>>> 
>>> @ActionMethod(parameters = {"firstNumber", "secondNumber"})  
>>> 
>>> Evan
>>> 
>>> 
>>> On Oct 5, 2010, at 6:48 AM, Poitras Christian wrote:
>>> 
>>> 
>>>> It's a problem that we faced in MyBatis when dealing with multiple 
>>>> parameters. We went with the annotation approach.
>>>> I guess there are many workarounds for that and Spring is probably using 
>>>> one. Debug seems like a good workaround.
>>>> 
>>>> Christian
>>>> 
>>>> -Message d'origine-
>>>> De : Freddy Daoud [mailto:xf2...@fastmail.fm] 
>>>> Envoyé : October-05-10 8:40 AM
>>>> À : Stripes Users List
>>>> Objet : Re: [Stripes-users] Stripes Development and its Future... (long)
>>>> 
>>>> Are you sure? I think that if you compile with debug info turned
>>>> on, and your request parameters are named param1 and param2,
>>>> they will be bound correctly without the need for the annotations.
>>>> 
>>>> Or is that what you meant by "you will need the source code"?
>>>> 
>>>> Cheers,
>>>> Freddy
>>>> 
>>>> On Tue, 5 Oct 2010 08:36:43 -0400, "Poitras Christian"
>>>>  said:
>>>> 
>>>>> A problem with the Spring approach is that parameter names are not
>>>>> accessible by reflection.
>>>>> The consequence is that if you have method like
>>>>> public void substract(int param1, int param2)
>>>>> It will be difficult to pass the parameters in the right order. You will
>>>>> need either the source code to find the parameter names or an annotation
>>>>> like
>>>>> public void substract(@Param("param1") int param1, @Param("param2") int
>>>>> param2)
>>>>> 
>>>>> Stripes is not affected by that problem.
>>>>> 
>>>>> Christian
>>>>> 
>>>>> -Message d'origine-
>>>>> De : Evan Leonard [mailto:evan.leon...@gmail.com] 
>>>>> Envoyé : October-04-10 4:59 PM
>>>>> À : Stripes Users List
>>>>> Objet : Re: [Stripes-users] Stripes Development and its Future... (long)
>>>>> 
>>>>> +1.  Though it will take one of us being dissatisfied *enough* to
>>>>

Re: [Stripes-users] Associating Parameters to Specific Actions

[Evan Leonard]

Hi Remi,

Good question about the views. There's a couple ways to consider going there.

There's already got $actionBean in the request attributes, so I initially 
thought $actionParams could also be put in the request attributes. This would 
just be a map from paramName -> bound param value.   Then I looked into the 
number of places that the request attribute key for "actionBean" is used and 
its quite a few (going in and out of flash scope for instance).  This made me 
rethink my approach, and instead try to piggy-back on top of all of the moving 
around of the actionBean that Stripes already does.

Where I'm at right now is that the parameter value map would be available on 
the ActionBeanContext as a new property. Then in your view you could do 
something like this:

$actionBean.context.boundParams.myParam

Its a little bit of a mouthful, but it would provide access to the parameters 
without having much impact on existing code. And you could always create a 
shortcut to it like its common to do with contextPath:

<#assign contextPath = actionBean.context.request.contextPath/>
<#assign params = actionBean.context.boundParams/>

As a more of a general comment, the reason I'm interested in this is that when 
you first look at Stripes' competitors, action parameter binding is one of the 
first things that makes people go "oooh neat!". It gets back to that thread we 
had about the "perception" of being stale, stagnant, and old.  I know that 
adding parameter binding might be perceived as a running counter to the KISS 
values that have made Stripes great, but I think the change might be worth the 
benefit.

What do other's think?

Evan

PS, I basically have a working prototype of this. Here's a sample of a passing 
test using parameter binding:



@UrlBinding("/ParameterResolverTests.action")
public class ParameterBindingTests implements ActionBean {

private ActionBeanContext context;
private String bindingResult;

public ActionBeanContext getContext() { return context; }
public void setContext(ActionBeanContext context) { this.context = context; 
}

@ParamBinding({"name","number"})
public Resolution basicParams(String name, int value) {

bindingResult = name + " " + value;
return null;
}

public String getBindingResult() {
return bindingResult;
}

// Start of Test Methods

@Test(groups="fast")
public void testBasicParamBinding() throws Exception {
MockRoundtrip trip = new 
MockRoundtrip(StripesTestFixture.getServletContext(), getClass());
trip.addParameter("name", "myname");
trip.addParameter("number", "2");
trip.addParameter(StripesConstants.URL_KEY_EVENT_NAME, 
"basicParams|name|number");
trip.execute();

ParameterBindingTests bean = trip.getActionBean( getClass() );
Assert.assertEquals(bean.getBindingResult(), "myname 2");

String s = (String) bean.getContext().getBoundParams().get("name");
Assert.assertEquals(s, "myname");
}

}




On Oct 6, 2010, at 3:06 PM, VANKEISBELCK Remi wrote:

> Hi folks,
> 
> There's one thing though, what about the views ?
> One cool aspect of the stripes way is that you access the bean
> directly from the view, usually using el, like "actionBean.myProp".
> The values accessed are often bound by stripes on the bean.
> Now, if you pass bound objects to a handler method, how will you
> access those values from your jsps ?
> If you have to use bean state for that, you still have your initial
> problem : you'll need accessors, and you won't know easily where (in
> views this time) props are used.
> In spring there is the ModelAndView indirection : a kind of binding
> passed to the view with all needed data. that doesn't exist in stripes
> : views access the bean directly.
> So imho the current system is sufficient, and most of all, it's simple.
> In most cases, when your validation and binding becomes complex,
> you'll probably make it much simpler by just breaking your one fat
> action into several smaller ones...
> Cheers
> Remi
> 
> 2010/10/6, Poitras Christian :
>> It could be a good idea to keep both binders separate and have a aggregate
>> binder that uses both sub-binders. That would allow full flexibility.
>> What do you think?
>> 
>> Christian
>> 
>> -Message d'origine-
>> De : Evan Leonard [mailto:evan.leon...@gmail.com]
>> Envoyé : October-05-10 5:42 PM
>> À : Stripes Users List
>> Objet : Re: [Stripes-users] Associating Parameters to Specific Actions
>> 
>> 
>> I was thinking it would be possible to use 

[Stripes-users] Rather basic question about flashScope and ValidationErrors

[Evan Leonard]

Hi all,

I have a ActionBean that may receive a post from a source page other than 
itself.  Though, if validation fails i'd like to redirect back to this 
ActionBean's default hanlder. What I've tried so far is to implement 
ValidationErrorHandler and then add this method:

public Resolution handleValidationErrors(ValidationErrors errors) throws 
Exception
{
return new RedirectResolution(getClass());
}

I've also tried this:
return new RedirectResolution(getClass()).flash(this);

>From what I've read, I thought that the errors would automatically be carried 
>over to the next request via flash scope. I've done a little tracing and can 
>see that they do get carried over, but then get wiped out in the next request 
>in the method named AnnotatedClassActionResolver.setActionBeanContext 

I'm certain I'm missing something basic here. Freddy's book makes it sound like 
the errors will get carried over automatically, though that appears not be the 
case.

What am I missing?

Thanks



--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users

Re: [Stripes-users] Associating Parameters to Specific Actions

[Evan Leonard]

Yup, sounds like I misjudged the appetite for a change like this.  That's ok, 
half the benefit of digging into this was getting to know the insides of my new 
set of tools (Stripes).
I'll shelve my work on this for a while until I've got more time under my belt 
with the framework, maybe I'll come to love the stateful bean paradigm too.

I also did some work on Rest/Http verb binding to handlers. Is this something 
folks have more interest in? I sent a patch to the dev list but didn't get much 
feedback. Here's what that looks like. This was a much smaller change :)


@UrlBinding("/RestAction")
public class RestActionBean implements ActionBean {

  @RestBinding("PUT")
   public Resolution myPutHandler() {
   log.info("Got a Put");
   return null;
   }
}

A PUT request to "/yourapp/RestAction", will be routed to the "myPutHandler" 
method.


Evan



On Oct 7, 2010, at 7:02 PM, Ross Sargant wrote:

> Fair enough, but I think that is largely a matter of personal preference.
> 
> If you split a complex action bean whose events currently share bean 
> properties  into multiple beans, then you'll probably wind up with 
> duplication across the beans. Possibly even more then you would having to 
> duplicate event names in "on={...}" lists or otherwise. That starts to get 
> really bad if it forces you into duplicating validation rules.
> 
> Still, I  agree that having a single large action bean whose events handle 
> large sets of independent  properties probably isn't the greatest thing 
> maintenance wise . 
> 
> I just find the on={} construct a little awkward to work with when you are in 
> the "grey" area and there is some significant (but not total) cross-over 
> between the events . It really isn't a big deal though.
> 
> Changing stripes to event method parameter binding feels like a real paradigm 
> shift. Nothing wrong with that if there are good reasons to do it.  I'm just 
> not sure what they are and it doesn't sound like I'm the only one..
> 
> 
> 
> 
> 
> 2010/10/7 Grzegorz Krugły 
>  Just my 2 cents - I think that if You have many action fields that are
> not used in some of the events, Your action is too big and should be split.
> 
> Solutions to the problem involving additional annotations and other ways
> of duplicating field names in another configuration structures seem ugly
> to me -- they just add more complexity to a complex action bean that
> should be simplified instead so it remains maintainable.
> 
> 
> --
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating great
> experiences on the web. Be a part of the beta today.
> http://p.sf.net/sfu/beautyoftheweb
> ___
> Stripes-users mailing list
> Stripes-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/stripes-users
> 
> 
> 
> -- 
> Ross Sargant
> Software Engineer
> p: 954-623-6015 x2108
> email: rsarg...@tvrc.com
> 
> TVR Communications LLC
> 541 S. State Road 7,Suite 5,Margate, Florida,33068
> 
> http://www.tvrc.com
> 
> --
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating great
> experiences on the web. Be a part of the beta today.
> http://p.sf.net/sfu/beautyoftheweb___
> Stripes-users mailing list
> Stripes-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/stripes-users

--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users

Re: [Stripes-users] Stripes Development and its Future...

[Evan Leonard]

Very good point.  I'm running intellistripes in IDEA 9.0.3 and get 
semi-frequent errors. Such as:


String index out of range: 12: String index out of range: 12
java.lang.StringIndexOutOfBoundsException: String index out of range: 12
at java.lang.String.substring(String.java:1934)
at com.intellij.openapi.util.TextRange.substring(TextRange.java:70)
at 
org.intellij.stripes.reference.SetterReferenceExSet.initRefs(SetterReferenceExSet.java:71)
at 
org.intellij.stripes.reference.StripesReferenceSetBase.(StripesReferenceSetBase.java:62)
at 
org.intellij.stripes.reference.SetterReferenceExSet.(SetterReferenceExSet.java:38)
at 
org.intellij.stripes.reference.contributors.SetterReferenceContributor$4.getReferencesByElement(SetterReferenceContributor.java:232)
at 
com.intellij.psi.impl.source.resolve.reference.ReferenceProvidersRegistry.getReferencesFromProviders(ReferenceProvidersRegistry.java:245)
at 
com.intellij.psi.impl.source.tree.java.PsiLiteralExpressionImpl.getReferences(PsiLiteralExpressionImpl.java:449)
at 
com.intellij.psi.impl.SharedPsiElementImplUtil.a(SharedPsiElementImplUtil.java:66)
at 
com.intellij.psi.impl.SharedPsiElementImplUtil.findReferenceAt(SharedPsiElementImplUtil.java:49)
at 
com.intellij.psi.impl.SharedPsiElementImplUtil.findReferenceAt(SharedPsiElementImplUtil.java:62)
at 
com.intellij.extapi.psi.PsiElementBase.findReferenceAt(PsiElementBase.java:123)
at 
com.intellij.psi.SingleRootFileViewProvider.a(SingleRootFileViewProvider.java:358)
at 
com.intellij.psi.SingleRootFileViewProvider.findReferenceAt(SingleRootFileViewProvider.java:327)
at 
com.intellij.psi.impl.source.PsiFileImpl.findReferenceAt(PsiFileImpl.java:504)
   ...

and


null
com.intellij.openapi.project.IndexNotReadyException
at com.intellij.util.indexing.FileBasedIndex.a(FileBasedIndex.java:719)
at 
com.intellij.util.indexing.FileBasedIndex.ensureUpToDate(FileBasedIndex.java:664)
at com.intellij.psi.stubs.StubIndexImpl.get(StubIndexImpl.java:161)
at 
com.intellij.psi.stubs.AbstractStubIndex.get(AbstractStubIndex.java:34)
at 
com.intellij.psi.impl.java.stubs.index.JavaSuperClassNameOccurenceIndex.get(JavaSuperClassNameOccurenceIndex.java:45)
at 
com.intellij.psi.impl.search.JavaDirectInheritorsSearcher$4.compute(JavaDirectInheritorsSearcher.java:71)
at 
com.intellij.psi.impl.search.JavaDirectInheritorsSearcher$4.compute(JavaDirectInheritorsSearcher.java:70)
at 
com.intellij.openapi.application.impl.ApplicationImpl$10.run(ApplicationImpl.java:727)
at 
com.intellij.openapi.application.impl.ApplicationImpl.runReadAction(ApplicationImpl.java:697)
at 
com.intellij.openapi.application.impl.ApplicationImpl.runReadAction(ApplicationImpl.java:725)
at 
com.intellij.psi.impl.search.JavaDirectInheritorsSearcher.execute(JavaDirectInheritorsSearcher.java:69)
at 
com.intellij.psi.impl.search.JavaDirectInheritorsSearcher.execute(JavaDirectInheritorsSearcher.java:27)
at 
com.intellij.util.ExecutorsQuery.processResults(ExecutorsQuery.java:35)
...

On Oct 8, 2010, at 6:20 AM, Daniel D'Alessandro wrote:

> I'd just like to weigh in on what I think is an important factor when 
> someone evaluates a framework that, hasn't got a mention. That's IDE 
> support for the framework. People have been talking about activity on 
> the mailing lists as important for perception but the lack of a plugin 
> for say Eclipse (at least a quick search couldn't find one) would 
> probably tip the balance for a lot of people in favour of something that 
> does.
> 
> Stripes is simple enough that plugins aren't really necessary but the 
> excellent IntelliStripes for Intellij really makes a big difference in 
> day to day use with its autocompletion of field bindings, variables etc. 
> Even then, this plugin has been slow to get its functionality back up to 
> scratch after the release of Intellij 9.
> 
> Dan
> 
> On 6/10/10 6:19 AM, stripes-users-requ...@lists.sourceforge.net wrote:
>> Re: [Stripes-users] Stripes Development and its Future...
>> 
> 
> 
> --
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating great
> experiences on the web. Be a part of the beta today.
> http://p.sf.net/sfu/beautyoftheweb
> ___
> Stripes-users mailing list
> Stripes-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/stripes-users


--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing 

Re: [Stripes-users] Rather basic question about flashScope and ValidationErrors

[Evan Leonard]

Gotcha. Well its really the messages I want anyhow. I haven't gotten to look at 
this closely again. I think I have a messages tag on the view but it still 
wasn't showing the error messages. I'll confirm this though.
Thanks for looking into this Ben.

Evan


On Oct 8, 2010, at 7:11 AM, Ben Gunter wrote:

> Looking at the svn log, this came up when I was fixing some file 
> upload-related stuff in May, 2008. There is one little line in the log (r921) 
> that indicates we agreed that validation errors should not carry forward on a 
> flash/redirect. This is just a note to let you know this has come up before, 
> and Stripes is doing what is intended. Messages survive; errors don't.
> 
> -Ben
> 
> On Thu, Oct 7, 2010 at 6:39 PM, Evan Leonard  wrote:
> 
> Hi all,
> 
> I have a ActionBean that may receive a post from a source page other than 
> itself.  Though, if validation fails i'd like to redirect back to this 
> ActionBean's default hanlder. What I've tried so far is to implement 
> ValidationErrorHandler and then add this method:
> 
>public Resolution handleValidationErrors(ValidationErrors errors) throws 
> Exception
>{
>return new RedirectResolution(getClass());
>}
> 
> I've also tried this:
>return new RedirectResolution(getClass()).flash(this);
> 
> >From what I've read, I thought that the errors would automatically be 
> >carried over to the next request via flash scope. I've done a little tracing 
> >and can see that they do get carried over, but then get wiped out in the 
> >next request in the method named 
> >AnnotatedClassActionResolver.setActionBeanContext
> 
> I'm certain I'm missing something basic here. Freddy's book makes it sound 
> like the errors will get carried over automatically, though that appears not 
> be the case.
> 
> What am I missing?
> 
> Thanks
> 
> 
> 
> --
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating great
> experiences on the web. Be a part of the beta today.
> http://p.sf.net/sfu/beautyoftheweb
> ___
> Stripes-users mailing list
> Stripes-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/stripes-users
> 
> --
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating great
> experiences on the web. Be a part of the beta today.
> http://p.sf.net/sfu/beautyoftheweb___
> Stripes-users mailing list
> Stripes-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/stripes-users

--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users

Re: [Stripes-users] Help with app security

[Evan Leonard]

What's the implementation of ctx.setLoginID(foundUser) look like?

I should look something like this:

getRequest().getSession().setAttribute(USER_KEY, currentUser);

Here's my action bean context with a few other fun things on it:

public class KonoActionBeanContext extends ActionBeanContext
{
public static final String USER_KEY = "com.kono.session.user";

public Person getCurrentUser()
{
return (Person) getRequest().getSession().getAttribute(USER_KEY);
}

public void setCurrentUser(Person currentUser)
{
 getRequest().getSession().setAttribute(USER_KEY, currentUser);   
}



public String getFullBaseUrl() {
String fullServerUrl = getRequest().getServerName();

int port = getRequest().getServerPort();
if(port != 80) {
fullServerUrl += ":"+getRequest().getServerPort();
}

return fullServerUrl;
}

public String getLastUrl() {
String s = getRequest().getServletPath();
return s;
}

//  COOKIE CODE 

private void deleteCookie(String cookieName, String domain)
{
setCookie(cookieName, domain, "Deleted", 0);// time 
of 0 means delete
}

private void setSessionCookie(String cookieName, String cookieData)
{
// let session cookie domain be null so it distinguishes 
between domains
setCookie(cookieName, null, cookieData, -1);
}

private void setCookie(String cookieName, String domain, String 
cookieData, int durationInSeconds)
{
Cookie cookie = new Cookie(cookieName, cookieData);
if(domain != null) {
cookie.setDomain(domain);
}
cookie.setMaxAge(durationInSeconds);
cookie.setPath("/");
getResponse().addCookie(cookie);
}

private static Cookie getCookie(HttpServletRequest request, String 
cookieName)
{
Cookie[] cookies = request.getCookies();
if(cookies != null)
{
for(Cookie cookie : cookies)
{
if(cookie.getName().equals(cookieName))
{
return cookie;
}
}
}

return null;
}

private static final Pattern ipRegex = 
Pattern.compile("^[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}.*"); // not 
perfect as it'll match 999.999.999.999 etc.
private String getRootCookieDomain() {
String requestDomain = getRequest().getServerName();
if(requestDomain.startsWith("localhost") || 
ipRegex.matcher(requestDomain).matches()) {
// localhost shouldn't set the domain, nor should 
direct ip queries
return null;
}

if(requestDomain.startsWith("my.")) {
requestDomain = requestDomain.substring(3);
} else if(requestDomain.startsWith("www.")) {
requestDomain = requestDomain.substring(4);
}

return "."+requestDomain;
}
}


On Oct 12, 2010, at 12:14 PM, John Berninger wrote:

> Folks -
> 
> I'm having some problems figuring out security in Stripes.  I'm attempting to 
> use the J2EESecurityManager model described in the Stripes book, and I'm 
> missing something obvious...
> 
> I set up a login action that sets a user ID and is supposed to (or so I 
> thought) signal to the security manager that "hey, I'm logged in".  When I 
> then redirect to an action bean that I've marked as requiring a certain role, 
> I get a 401 error message saying "This request requires HTTP 
> authentication()."
> 
> I'm attaching my security manager class, the login action bean, and the bean 
> requiring the user be logged in.  Any help on where I went wrong would be 
> appreciated.
> 
> --
> John
> 
> -- 
> John
> 
> package util;
> 
> import org.stripesstuff.plugin.security.*;
> 
> import daoimpl.RoleDao;
> import net.sourceforge.stripes.action.*;
> import java.lang.reflect.*;
> import java.util.*;
> import model.*;
> import action.*;
> import org.apache.log4j.*;
> public class HaxSecurityManager extends J2EESecurityManager {
>   private static Logger log = Logger.getLogger(HaxSecurityManager.class);
>   
>   @Override
>   protected Boolean isUserAuthenticated(ActionBean bean, Method handler) {
>   return getUser(bean) != null;
>   }
>   
>   @Override
>   protected Boolean hasRole(ActionBean actionBean, Method handler, String 
> role) {
>   log.debug("Checking for role");
>

Re: [Stripes-users] Help with app security

[Evan Leonard]

So when you debug this, 
1) is getUser(actionBean) returning null?  
2) is user.getRoles() returning null?
3) is RoleDao.getInstance().findByRoleName(role) returning null?
4) does roles.contains(RoleDao.getInstance().findByRoleName(role)) return null?


Evan




On Oct 12, 2010, at 12:14 PM, John Berninger wrote:

> Folks -
> 
> I'm having some problems figuring out security in Stripes.  I'm attempting to 
> use the J2EESecurityManager model described in the Stripes book, and I'm 
> missing something obvious...
> 
> I set up a login action that sets a user ID and is supposed to (or so I 
> thought) signal to the security manager that "hey, I'm logged in".  When I 
> then redirect to an action bean that I've marked as requiring a certain role, 
> I get a 401 error message saying "This request requires HTTP 
> authentication()."
> 
> I'm attaching my security manager class, the login action bean, and the bean 
> requiring the user be logged in.  Any help on where I went wrong would be 
> appreciated.
> 
> --
> John
> 
> -- 
> John
> 
> package util;
> 
> import org.stripesstuff.plugin.security.*;
> 
> import daoimpl.RoleDao;
> import net.sourceforge.stripes.action.*;
> import java.lang.reflect.*;
> import java.util.*;
> import model.*;
> import action.*;
> import org.apache.log4j.*;
> public class HaxSecurityManager extends J2EESecurityManager {
>   private static Logger log = Logger.getLogger(HaxSecurityManager.class);
>   
>   @Override
>   protected Boolean isUserAuthenticated(ActionBean bean, Method handler) {
>   return getUser(bean) != null;
>   }
>   
>   @Override
>   protected Boolean hasRole(ActionBean actionBean, Method handler, String 
> role) {
>   log.debug("Checking for role");
>   Person user = getUser(actionBean);
>   if ( user != null ) {
>   Collection roles = user.getRoles();
>   if ( null == roles ) {
>   return false;
>   }
>   return roles != null && 
> roles.contains(RoleDao.getInstance().findByRoleName(role));
>   }
>   return false;
>   }
>   
>   private Person getUser(ActionBean bean) {
>   MyActionBeanContext ctx = (MyActionBeanContext) 
> ((BaseActionBean) bean).getContext();
>   Person user = ctx.getLoginID();
>   try {
>   log.debug("Found current logged in user " + 
> user.getUsername());
>   }
>   catch (Exception e) {
>   log.warn("Error in current logged in user object - " + 
> e.getMessage());
>   }
>   return user;
>   }
> }
> package action;
> 
> import net.sourceforge.stripes.action.*;
> import javax.annotation.security.*;
> 
> @RolesAllowed("User")
> public class HomeActionBean extends BaseActionBean {
>   private static final String HOMEPAGE = "/WEB-INF/jsp/home.jsp";
>   
>   @DefaultHandler
>   public Resolution mainForm() {
>   return new ForwardResolution(HOMEPAGE);
>   }
> }
> package action;
> 
> import daoimpl.*;
> import model.*;
> import util.*;
> import net.sourceforge.stripes.action.*;
> import org.apache.log4j.*;
> 
> public class LoginActionBean extends BaseActionBean {
>   private String username;
>   private String password;
>   private static Logger log = Logger.getLogger(LoginActionBean.class);
>   
>   public void setUsername(String username) {
>   this.username = username;
>   }
>   
>   public String getUsername() {
>   return username;
>   }
> 
>   public void setPassword(String password) {
>   this.password = password;
>   }
> 
>   public String getPassword() {
>   return password;
>   }
>   
>   @DefaultHandler
>   public Resolution noName() {
>   return new RedirectResolution(GreeterActionBean.class);
>   }
>   
>   public Resolution login() {
>   log.debug("Starting login process");
>   Person foundUser = 
> UserDao.getInstance().findUserByName(getUsername());
>   if ( null == foundUser ) {
>   log.warn("Username not found in database");
>   getContext().getMessages().add(new SimpleMessage("The 
> specified username was not found in our database.  Please create an account 
> before attempting to log in."));
>   return new RedirectResolution(GreeterActionBean.class);
>   }
>   if ( getPassword().equals(foundUser.getPassword()) ) {
>   MyActionBeanContext ctx = 
> (MyActionBeanContext)getContext();
>   ctx.setLoginID(foundUser);
>   log.debug("Logging in user " + this.username);
>   return new RedirectResolution(HomeActionBean.class);
> 

Re: [Stripes-users] Help with app security

[Evan Leonard]

No worries, glad you got it going 

Sent from my iPhone

On Oct 13, 2010, at 9:00 AM, John Berninger  wrote:

> Evan Leonard wrote:
>> So when you debug this, 
>> 1) is getUser(actionBean) returning null?  
>> 2) is user.getRoles() returning null?
>> 
> No, but it's returning an empty list, because I was stupid in the user 
> creation code.  My apologies, I'll go fix my bug and re-test.
> 
> -- 
> John
> 
> 
> --
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating great
> experiences on the web. Be a part of the beta today.
> http://p.sf.net/sfu/beautyoftheweb
> ___
> Stripes-users mailing list
> Stripes-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/stripes-users

--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users

Re: [Stripes-users] Source forge description: It's stripey and it doesn't suck

[Evan Leonard]

I like it.

On Oct 28, 2010, at 2:26 PM, Søren Pedersen wrote:

> What about:
> Stripes - because it's simple
> 
> 
>> Den 28/10/2010 22.14 skrev "Nikolaos Giannopoulos" 
>> :
>> 
>> On a more serious note... I agree with Karen.
>> 
>> In fact... IMO its always better in marketing to differentiate yourself
>> (and speak to your audience) with what you do well...
>> 
>> How about something like:
>> "Stripes:  The robust and intuitive Java web framework"
>> 
>> --Nikolaos
>> 
>> 
>> > 2010/10/28 Freddy Daoud mailto:xf2...@fastmail.fm>>
>> >
>> > > On the source forge page of Stripes I see the text:
>> > >
>> > > "Source forge descript...
>> 
>> > 
>> > https://lists.sourceforge.net/lists/listinfo/stripes-users
>> >
>> >
>> 
>> --...
>> 
> 
> --
> Nokia and AT&T present the 2010 Calling All Innovators-North America contest
> Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
> http://p.sf.net/sfu/nokia-dev2dev___
> Stripes-users mailing list
> Stripes-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/stripes-users

--
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users

Re: [Stripes-users] Source forge description: It's stripey and it doesn't suck

[Evan Leonard]

the other thing that people keep talking about is how Stripes is (or nearly is) 
"feature complete".  So how about:

Stripes - simple & complete.


On Oct 28, 2010, at 2:26 PM, Søren Pedersen wrote:

> What about:
> Stripes - because it's simple
> 
> 
>> Den 28/10/2010 22.14 skrev "Nikolaos Giannopoulos" 
>> :
>> 
>> On a more serious note... I agree with Karen.
>> 
>> In fact... IMO its always better in marketing to differentiate yourself
>> (and speak to your audience) with what you do well...
>> 
>> How about something like:
>> "Stripes:  The robust and intuitive Java web framework"
>> 
>> --Nikolaos
>> 
>> 
>> > 2010/10/28 Freddy Daoud mailto:xf2...@fastmail.fm>>
>> >
>> > > On the source forge page of Stripes I see the text:
>> > >
>> > > "Source forge descript...
>> 
>> > 
>> > https://lists.sourceforge.net/lists/listinfo/stripes-users
>> >
>> >
>> 
>> --...
>> 
> 
> --
> Nokia and AT&T present the 2010 Calling All Innovators-North America contest
> Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
> http://p.sf.net/sfu/nokia-dev2dev___
> Stripes-users mailing list
> Stripes-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/stripes-users

--
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users

Re: [Stripes-users] Source forge description: It's stripey and it doesn't suck

[Evan Leonard]

or maybe:

Stripes: What's needed, nothing more.


On Oct 29, 2010, at 8:32 AM, Oscar Westra van Holthe - Kind wrote:

> On 29-10-2010 at 09:11, Rick Grashel wrote:
>> When I used Stripes for the first time, my initial thought was... "This is
>> the missing thing I've been looking for."  Every Java-based web framework I
>> looked at either had a piece missing or had too much things that I didn't
>> need.
>> 
>> I'm not the best tag-line person, but I propose something that indicates
>> that Stripes is the missing piece... or perhaps that Stripes is exactly what
>> someone needs... or something along those lines.
> 
> You mean: "Stripes: this missing piece in any webapp."
> Or maybe: "Stripes: the piece to connect it all together."
> 
> 
> Oscar
> 
> -- 
>   ,-_
>  /() ) Oscar Westra van Holthe - Kind  http://www.xs4all.nl/~kindop/
> (__ (
> =/  ()  A half truth is a whole lie.  -- Yiddish Proverb
> --
> Nokia and AT&T present the 2010 Calling All Innovators-North America contest
> Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
> http://p.sf.net/sfu/nokia-dev2dev___
> Stripes-users mailing list
> Stripes-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/stripes-users


--
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev
___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users

Re: [Stripes-users] Source forge description: It's stripey and itdoesn't suck

[Evan Leonard]

I like that one too


On Oct 29, 2010, at 9:29 AM, Edward Smith wrote:

> I think you're on to something there Nikolaos:
>  
> "Stripes: Write less, do more"
>  
> Edward Smith
> Senior Software Developer
> 214-272-5225 (direct)
> esm...@peopleanswers.com
> 
> PeopleAnswers®  
>   Better Insight.  Better People.
> 
>  Check out our blog: blog.peopleanswers.com
> 
> CONFIDENTIALITY NOTE: This email (including any attachments) is confidential 
> and may be protected by legal privilege. If you are not the intended 
> recipient, be aware that any disclosure, copying, distribution, or use of the 
> information contained herein is prohibited.  If you have received this 
> message in error, please notify the sender by replying to this message and 
> then delete this message in its entirety. Thank you for your cooperation.
>  
> From: Nikolaos Giannopoulos [mailto:nikol...@brightminds.org] 
> Sent: Friday, October 29, 2010 10:21 AM
> To: Stripes Users List
> Subject: Re: [Stripes-users] Source forge description: It's stripey and 
> itdoesn't suck
>  
> Don't want to interrupt this brain storming on "missing" but after having 
> experienced so many other frameworks my thoughts about Stripes were wow...
> 
> It does so much more for you that you actually write less code.  Moreover it 
> does things "smarter" than other frameworks so you end up writing less code.
> 
> SO how about a play on Java's "write once; run anywhere."
> 
> "Stripes: write less; run smarter."
> 
> OR
> 
> "Stripes: write less; run more."
> 
> :-)
> 
> --Nikolaos
> 
> 
> 
> Oscar Westra van Holthe - Kind wrote:
> On 29-10-2010 at 16:37, jfonta...@codegap.com wrote:
>   
> "Stripes: the missing link"? ;)
> 
>  
> Better.
>  
>  
> Oscar
>  
>   
>  
> 
> 
>  
> --
> Nokia and AT&T present the 2010 Calling All Innovators-North America contest
> Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
> http://p.sf.net/sfu/nokia-dev2dev
>  
> 
> 
>  
> ___
> Stripes-users mailing list
> Stripes-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>   
>  
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1153 / Virus Database: 424/3225 - Release Date: 10/28/10
> 
> --
> Nokia and AT&T present the 2010 Calling All Innovators-North America contest
> Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
> http://p.sf.net/sfu/nokia-dev2dev___
> Stripes-users mailing list
> Stripes-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/stripes-users

--
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store 
http://p.sf.net/sfu/nokia-dev2dev___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users

Re: [Stripes-users] [Stripes-dev] Stripes 1.5.4 released

[Evan Leonard]

Good work!

Thank you,
Evan


On Nov 10, 2010, at 3:29 AM, VANKEISBELCK Remi wrote:

> Thanks dude !
> 
> Cheers
> 
> Remi
> 
> 2010/11/10 Ben Gunter 
> It's available from Sourceforge now, and it should sync to Maven central 
> soon. Here's a list of changes since 1.5.3:
> 
> http://stripesframework.org/jira/browse/STS?report=com.atlassian.jira.plugin.system.project:changelog-panel
> 
> -Ben
> 
> --
> The Next 800 Companies to Lead America's Growth: New Video Whitepaper
> David G. Thomson, author of the best-selling book "Blueprint to a
> Billion" shares his insights and actions to help propel your
> business during the next growth cycle. Listen Now!
> http://p.sf.net/sfu/SAP-dev2dev
> ___
> Stripes-development mailing list
> stripes-developm...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/stripes-development
> 
> 
> --
> The Next 800 Companies to Lead America's Growth: New Video Whitepaper
> David G. Thomson, author of the best-selling book "Blueprint to a 
> Billion" shares his insights and actions to help propel your 
> business during the next growth cycle. Listen Now!
> http://p.sf.net/sfu/SAP-dev2dev___
> Stripes-development mailing list
> stripes-developm...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/stripes-development

--
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a 
Billion" shares his insights and actions to help propel your 
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users