You can subscribe to this list here.
2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(18) |
Oct
(9) |
Nov
(25) |
Dec
(1) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2006 |
Jan
(28) |
Feb
(46) |
Mar
(212) |
Apr
(225) |
May
(77) |
Jun
(86) |
Jul
(88) |
Aug
(132) |
Sep
(113) |
Oct
(132) |
Nov
(67) |
Dec
(37) |
2007 |
Jan
(31) |
Feb
(27) |
Mar
(176) |
Apr
(103) |
May
(173) |
Jun
(78) |
Jul
(56) |
Aug
(76) |
Sep
(54) |
Oct
(92) |
Nov
(171) |
Dec
(229) |
2008 |
Jan
(276) |
Feb
(147) |
Mar
(73) |
Apr
(90) |
May
(146) |
Jun
(36) |
Jul
(36) |
Aug
(28) |
Sep
(27) |
Oct
(118) |
Nov
(32) |
Dec
(70) |
2009 |
Jan
(42) |
Feb
(90) |
Mar
(138) |
Apr
(58) |
May
(14) |
Jun
(25) |
Jul
(19) |
Aug
(17) |
Sep
(84) |
Oct
(167) |
Nov
(58) |
Dec
(20) |
2010 |
Jan
(7) |
Feb
(11) |
Mar
(12) |
Apr
(7) |
May
(96) |
Jun
(44) |
Jul
(9) |
Aug
(9) |
Sep
(144) |
Oct
(43) |
Nov
(197) |
Dec
(52) |
2011 |
Jan
(296) |
Feb
(36) |
Mar
(65) |
Apr
(43) |
May
(44) |
Jun
(39) |
Jul
(23) |
Aug
(16) |
Sep
(20) |
Oct
(9) |
Nov
(27) |
Dec
(77) |
2012 |
Jan
(8) |
Feb
(69) |
Mar
(32) |
Apr
(4) |
May
(53) |
Jun
(9) |
Jul
|
Aug
(11) |
Sep
(1) |
Oct
(1) |
Nov
(13) |
Dec
(9) |
2013 |
Jan
(7) |
Feb
(28) |
Mar
(13) |
Apr
(3) |
May
(10) |
Jun
(6) |
Jul
(4) |
Aug
(4) |
Sep
(8) |
Oct
(5) |
Nov
(3) |
Dec
|
2014 |
Jan
(4) |
Feb
(3) |
Mar
(15) |
Apr
(53) |
May
(12) |
Jun
(4) |
Jul
(12) |
Aug
|
Sep
(2) |
Oct
(2) |
Nov
|
Dec
(1) |
2015 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
(3) |
Aug
(11) |
Sep
(1) |
Oct
|
Nov
(1) |
Dec
(4) |
2016 |
Jan
|
Feb
|
Mar
(6) |
Apr
(2) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(5) |
From: Ulf D. <ulf...@go...> - 2020-12-19 10:20:20
|
Thanks very much, I'll give that a try. Seems to be a different approach, and I need to dig into Stripes a bit to see how they differ. Ulf On Thu, Dec 17, 2020 at 3:04 PM Iwao AVE! <har...@gm...> wrote: > Hello Ulf, > > This is not what you requested, but I am the one who reported STS-433 and > the attached is my original patch (well, I believe it is). > I couldn't find Nikolaos' patches on my drive, though. > > If you have any questions, please let me know. > > Regards, > Iwao > > On Wed, Dec 16, 2020 at 9:18 PM Ulf Dittmer via Stripes-development < > str...@li...> wrote: > >> Hello- >> >> I'm not sure if anyone is still around here, but I'm looking for the file STS433_PATCH_VERSION_FIXED_3.txt >> which was referenced in >> https://stripesframework.atlassian.net/browse/STS-433 ("Localize title >> attribute for Stripes tags"). The patch did apparently not get moved over >> when the JIRA was migrated. >> >> The source code of the patched class (apparently >> net.sourceforge.stripes.tag.InputTagSupport) would also help. >> >> I tried contacting the original author, but no luck. >> >> Does anyone have any ideas? >> >> Cheers, >> Ulf >> _______________________________________________ >> Stripes-development mailing list >> Str...@li... >> https://lists.sourceforge.net/lists/listinfo/stripes-development >> > |
From: Iwao AVE! <har...@gm...> - 2020-12-17 14:04:26
|
Hello Ulf, This is not what you requested, but I am the one who reported STS-433 and the attached is my original patch (well, I believe it is). I couldn't find Nikolaos' patches on my drive, though. If you have any questions, please let me know. Regards, Iwao On Wed, Dec 16, 2020 at 9:18 PM Ulf Dittmer via Stripes-development < str...@li...> wrote: > Hello- > > I'm not sure if anyone is still around here, but I'm looking for the file STS433_PATCH_VERSION_FIXED_3.txt > which was referenced in > https://stripesframework.atlassian.net/browse/STS-433 ("Localize title > attribute for Stripes tags"). The patch did apparently not get moved over > when the JIRA was migrated. > > The source code of the patched class (apparently > net.sourceforge.stripes.tag.InputTagSupport) would also help. > > I tried contacting the original author, but no luck. > > Does anyone have any ideas? > > Cheers, > Ulf > _______________________________________________ > Stripes-development mailing list > Str...@li... > https://lists.sourceforge.net/lists/listinfo/stripes-development > |
From: Ulf D. <ulf...@go...> - 2020-12-17 10:39:46
|
I think it's safe to say that Stripes is dead, unless someone new steps up to maintain it going forward (unlikely IMO). I'm using 1.6 for a particular project, and have patched a few small things to address some bugs in order to continue using it. But basically, it's obsolete. On Thu, Dec 17, 2020 at 8:12 AM Anil Patel <ap...@cl...> wrote: > Hi, > > Unfortunately I cannot help with that issue. Hopefully someone else > from the stripes development community may assist you. > > Any idea when Stripes 1.7 will be officially released? Looks-like > version 1.7 has been stuck-in-a-rut for nearly 5 years now! > > Personally I think its a great, productive framework but needs to > catch-up with more 'fuller' open-source web frameworks. > > - > Regards, > -------------------------------------------------------- > Anil Patel MSc > m: +44 (0)7553 232279 > e: ap...@cl... > w: www.cloudmagic.uk and www.javamagic.uk > > *This transmission (including any attachments) may contain > confidential information, privileged material (including material > protected by the solicitor-client or other applicable privileges), or > constitute non-public information. Any use of this information by > anyone other than the intended recipient is prohibited. If you have > received this transmission in error, please immediately reply to the > sender and delete this information from your system. Use, > dissemination, distribution, or reproduction of this transmission by > unintended recipients is not authorized and may be unlawful. > > > On 16/12/2020, Ulf Dittmer via Stripes-development > <str...@li...> wrote: > > Hello- > > > > I'm not sure if anyone is still around here, but I'm looking for the > > file STS433_PATCH_VERSION_FIXED_3.txt > > which was referenced in > > https://stripesframework.atlassian.net/browse/STS-433 ("Localize title > > attribute for Stripes tags"). The patch did apparently not get moved over > > when the JIRA was migrated. > > > > The source code of the patched class (apparently > > net.sourceforge.stripes.tag.InputTagSupport) would also help. > > > > I tried contacting the original author, but no luck. > > > > Does anyone have any ideas? > > > > Cheers, > > Ulf > > > > > _______________________________________________ > Stripes-development mailing list > Str...@li... > https://lists.sourceforge.net/lists/listinfo/stripes-development > |
From: Anil P. <ap...@cl...> - 2020-12-17 07:12:05
|
Hi, Unfortunately I cannot help with that issue. Hopefully someone else from the stripes development community may assist you. Any idea when Stripes 1.7 will be officially released? Looks-like version 1.7 has been stuck-in-a-rut for nearly 5 years now! Personally I think its a great, productive framework but needs to catch-up with more 'fuller' open-source web frameworks. - Regards, -------------------------------------------------------- Anil Patel MSc m: +44 (0)7553 232279 e: ap...@cl... w: www.cloudmagic.uk and www.javamagic.uk *This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. On 16/12/2020, Ulf Dittmer via Stripes-development <str...@li...> wrote: > Hello- > > I'm not sure if anyone is still around here, but I'm looking for the > file STS433_PATCH_VERSION_FIXED_3.txt > which was referenced in > https://stripesframework.atlassian.net/browse/STS-433 ("Localize title > attribute for Stripes tags"). The patch did apparently not get moved over > when the JIRA was migrated. > > The source code of the patched class (apparently > net.sourceforge.stripes.tag.InputTagSupport) would also help. > > I tried contacting the original author, but no luck. > > Does anyone have any ideas? > > Cheers, > Ulf > |
From: Ulf D. <ulf...@go...> - 2020-12-16 12:18:02
|
Hello- I'm not sure if anyone is still around here, but I'm looking for the file STS433_PATCH_VERSION_FIXED_3.txt which was referenced in https://stripesframework.atlassian.net/browse/STS-433 ("Localize title attribute for Stripes tags"). The patch did apparently not get moved over when the JIRA was migrated. The source code of the patched class (apparently net.sourceforge.stripes.tag.InputTagSupport) would also help. I tried contacting the original author, but no luck. Does anyone have any ideas? Cheers, Ulf |
From: Poitras C. <Chr...@ir...> - 2018-06-21 10:58:59
|
Hi, Right now, your only option is to download the source code and build it yourself. Since I am not a developer of the framework, I cannot give any timeline for the actual release of version 1.7. Best, Christian From: Anil Patel <ap...@cl...> Reply-To: Stripes Development List <Str...@li...> Date: Thursday, June 21, 2018 at 3:07 AM To: "Str...@li..." <Str...@li...> Subject: Re: [Stripes-dev] Stripes v1.7 download and links.. Hi, What is the current state with regards to v1.7 of the Stripes framework? Where can I download the latest v1.7 from please? Thanks in advance, -------------------------------------------------------- Anil Patel MSc m: +44 (0)7553 232279 e: ap...@cl...<mailto:ap...@cl...> w: www.cloudmagic.co.uk<http://www.cloudmagic.co.uk> *This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. |
From: Anil P. <ap...@cl...> - 2018-06-21 07:06:59
|
Hi, What is the current state with regards to v1.7 of the Stripes framework? Where can I download the latest v1.7 from please? Thanks in advance, -------------------------------------------------------- Anil Patel MSc m: +44 (0)7553 232279 e: ap...@cl... w: www.cloudmagic.co.uk *This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. |
From: VANKEISBELCK R. <re...@rv...> - 2016-06-21 13:39:07
|
Hi folks, Stripes 1.7.0-beta4 is on its way to Maven Central. It's a minor bugfix release. Enjoy, Rémi |
From: VANKEISBELCK R. <re...@rv...> - 2016-04-27 08:19:43
|
Dear Stripers, 1.7.0-beta3 is on its way to maven. It's a minor bugfix release that is java6-compatible (beta2 wasn't, thanks Iwao for pointing that out). Enjoy, Rémi |
From: VANKEISBELCK R. <re...@rv...> - 2016-04-26 11:27:51
|
Dear Stripers, 1.7.0-beta2 is on it way to maven central, and should be available in a few hours. It's a minor bugfix release. Enjoy, Rémi |
From: Rick G. <rgr...@gm...> - 2016-03-11 20:49:03
|
Hi Remi, I've never used the DMF, so I can't speak to its behavior. But considering the large amount of assumptions it makes, I would not be surprised if it did not work as you expect. But I can report that the use cases you are talking about will work 100% if they are mapped directly into the StripesDispatcher. -- Rick On Mar 11, 2016 2:44 PM, "VANKEISBELCK Remi" <re...@rv...> wrote: > Hi Rick, > > Strange, I have two actions bound at : > > /api/foo/{p} > /api/foo/{p}/bar/{q} > > And I have a conflict. > > I have DMF, maybe that's the reason for the problem ? I will try with a > mapped DispatcherServlet. > > Thanks > > Rémi > > 2016-03-11 20:21 GMT+01:00 Rick Grashel <rgr...@gm...>: > >> Hi Remi, >> >> I use this kind of a scheme by mapping API urls into the >> StripesDispatcher and then using @UrlBinding on API-based ActionBeans. So >> the web.xml would look like: >> >> <servlet-mapping> >> <servlet-name>StripesDispatcher</servlet-name> >> <url-pattern>/api/*</url-pattern> >> </servlet-mapping> >> >> Then, I would have two different action beans. The class declarations >> for those would look like this: >> >> @UrlBinding( "/api/major" ) >> public class MajorActionBean implements ActionBean >> >> @UrlBinding( "/api/major/{someNumber}" ) >> public class MajorMinorActionBean implements ActionBean >> >> Now, if I call "http://myapp/api/major", then "MajorActionBean" will be >> executed. If I call "http://myapp/api/major/1", then >> "MajorMinorActionBean" will be executed and the "someNumber" parameter will >> be bound to it. >> >> So Stripes does the correct thing in terms of using a "best-match" >> approach when it comes resolving UrlBindings to ActionBeans. It actually >> does a pretty good job. If you keep your API clean and simple, Stripes can >> resolve RESTful bindings extremely well, but if you are not consistent in >> how you design clean URLs, it will not work. In those situations, you will >> need to write you own resolver. >> >> Hope that helps, >> >> -- Rick >> >> >> >> On Fri, Mar 11, 2016 at 12:44 PM, VANKEISBELCK Remi <re...@rv...> >> wrote: >> >>> Hi, >>> >>> I want to create a REST API with the following endpoints : >>> >>> GET /api/store/{store} >>> GET /api/store/{store}/product/{product} >>> >>> Problem is that those URLs clash, and I get an exception :/ >>> >>> Can Stripes support such an URL scheme ? >>> >>> Cheers >>> >>> Rémi >>> >>> >>> ------------------------------------------------------------------------------ >>> Transform Data into Opportunity. >>> Accelerate data analysis in your applications with >>> Intel Data Analytics Acceleration Library. >>> Click to learn more. >>> http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140 >>> _______________________________________________ >>> Stripes-development mailing list >>> Str...@li... >>> https://lists.sourceforge.net/lists/listinfo/stripes-development >>> >>> >> > |
From: VANKEISBELCK R. <re...@rv...> - 2016-03-11 20:44:45
|
Hi Rick, Strange, I have two actions bound at : /api/foo/{p} /api/foo/{p}/bar/{q} And I have a conflict. I have DMF, maybe that's the reason for the problem ? I will try with a mapped DispatcherServlet. Thanks Rémi 2016-03-11 20:21 GMT+01:00 Rick Grashel <rgr...@gm...>: > Hi Remi, > > I use this kind of a scheme by mapping API urls into the StripesDispatcher > and then using @UrlBinding on API-based ActionBeans. So the web.xml would > look like: > > <servlet-mapping> > <servlet-name>StripesDispatcher</servlet-name> > <url-pattern>/api/*</url-pattern> > </servlet-mapping> > > Then, I would have two different action beans. The class declarations for > those would look like this: > > @UrlBinding( "/api/major" ) > public class MajorActionBean implements ActionBean > > @UrlBinding( "/api/major/{someNumber}" ) > public class MajorMinorActionBean implements ActionBean > > Now, if I call "http://myapp/api/major", then "MajorActionBean" will be > executed. If I call "http://myapp/api/major/1", then > "MajorMinorActionBean" will be executed and the "someNumber" parameter will > be bound to it. > > So Stripes does the correct thing in terms of using a "best-match" > approach when it comes resolving UrlBindings to ActionBeans. It actually > does a pretty good job. If you keep your API clean and simple, Stripes can > resolve RESTful bindings extremely well, but if you are not consistent in > how you design clean URLs, it will not work. In those situations, you will > need to write you own resolver. > > Hope that helps, > > -- Rick > > > > On Fri, Mar 11, 2016 at 12:44 PM, VANKEISBELCK Remi <re...@rv...> wrote: > >> Hi, >> >> I want to create a REST API with the following endpoints : >> >> GET /api/store/{store} >> GET /api/store/{store}/product/{product} >> >> Problem is that those URLs clash, and I get an exception :/ >> >> Can Stripes support such an URL scheme ? >> >> Cheers >> >> Rémi >> >> >> ------------------------------------------------------------------------------ >> Transform Data into Opportunity. >> Accelerate data analysis in your applications with >> Intel Data Analytics Acceleration Library. >> Click to learn more. >> http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140 >> _______________________________________________ >> Stripes-development mailing list >> Str...@li... >> https://lists.sourceforge.net/lists/listinfo/stripes-development >> >> > |
From: Rick G. <rgr...@gm...> - 2016-03-11 19:21:27
|
Hi Remi, I use this kind of a scheme by mapping API urls into the StripesDispatcher and then using @UrlBinding on API-based ActionBeans. So the web.xml would look like: <servlet-mapping> <servlet-name>StripesDispatcher</servlet-name> <url-pattern>/api/*</url-pattern> </servlet-mapping> Then, I would have two different action beans. The class declarations for those would look like this: @UrlBinding( "/api/major" ) public class MajorActionBean implements ActionBean @UrlBinding( "/api/major/{someNumber}" ) public class MajorMinorActionBean implements ActionBean Now, if I call "http://myapp/api/major", then "MajorActionBean" will be executed. If I call "http://myapp/api/major/1", then "MajorMinorActionBean" will be executed and the "someNumber" parameter will be bound to it. So Stripes does the correct thing in terms of using a "best-match" approach when it comes resolving UrlBindings to ActionBeans. It actually does a pretty good job. If you keep your API clean and simple, Stripes can resolve RESTful bindings extremely well, but if you are not consistent in how you design clean URLs, it will not work. In those situations, you will need to write you own resolver. Hope that helps, -- Rick On Fri, Mar 11, 2016 at 12:44 PM, VANKEISBELCK Remi <re...@rv...> wrote: > Hi, > > I want to create a REST API with the following endpoints : > > GET /api/store/{store} > GET /api/store/{store}/product/{product} > > Problem is that those URLs clash, and I get an exception :/ > > Can Stripes support such an URL scheme ? > > Cheers > > Rémi > > > ------------------------------------------------------------------------------ > Transform Data into Opportunity. > Accelerate data analysis in your applications with > Intel Data Analytics Acceleration Library. > Click to learn more. > http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140 > _______________________________________________ > Stripes-development mailing list > Str...@li... > https://lists.sourceforge.net/lists/listinfo/stripes-development > > |
From: VANKEISBELCK R. <re...@rv...> - 2016-03-11 18:44:32
|
Hi, I want to create a REST API with the following endpoints : GET /api/store/{store} GET /api/store/{store}/product/{product} Problem is that those URLs clash, and I get an exception :/ Can Stripes support such an URL scheme ? Cheers Rémi |
From: VANKEISBELCK R. <re...@rv...> - 2016-03-11 11:39:05
|
Dear Stripers, Asynchronous Actions are now available in master (1.7.0-SNAPSHOT). I have also released a beta, so that you don't need to build yourself : <dependency> <groupId>net.sourceforge.stripes</groupId> <artifactId>stripes</artifactId> <version>1.7.0-beta1</version> </dependency> (I've just released, so it might take a few hours to propagate to Maven Central) For those who haven't followed the conversations on github, Async Actions allow to write non-blocking/asynchronous event handlers, "a la Servlet3 async". The related wiki page (probably needs some improvements) : https://stripesframework.atlassian.net/wiki/display/STRIPES/Asynchronous+Actions The github ticket(s) : https://github.com/StripesFramework/stripes/issues/37 https://github.com/StripesFramework/stripes/issues/47 (tomcat bug) There's a (simple) async action in the examples webapp : https://github.com/StripesFramework/stripes/blob/master/examples/src/main/java/net/sourceforge/stripes/examples/async/AsyncActionBean.java As usual, feedback is most appreciated. Cheers Rémi |
From: VANKEISBELCK R. <re...@rv...> - 2016-03-08 15:42:05
|
Hi folks, I have a question related to "Configurations" in Stripes. Does anyone know why we have this "configuration stash" thread local in StripesFilter ? It doesn't play well with asynchronous actions : calling asyncResp.complete(forwardResolution) is not possible within another thread, and is unfortunate. I'm in favor of removing all this and replace by a static ref to the Configuration object in Stripes Filter. Any objections ? Cheers Rémi |
From: VANKEISBELCK R. <re...@rv...> - 2015-12-29 15:56:09
|
Hi Rick, Yep I know the rationale behind VFSs, but it comes from "back in the days", when classpath scanning wasn't standard :P My point is that now that it's provided by servlet containers (since years now), we could leverage this. I fully understand that we need to keep classpath scanning, be it only for unit tests. But having it working with servlet3 containers would allow us to avoid writing new VFSs all the time we find a problem. Let the container do it if it can. The draft I have commited works just like this : if you have the container initializer declared then it'll use container-scanned classes. Otherwise it'll default to the current VFS mechanism. Ultimately, we'd need only one implementation of the VFS for the unit tests. For all servlet3 containers we should use the container IMHO. Cheers Rémi 2015-12-29 16:11 GMT+01:00 Rick Grashel <rgr...@gm...>: > Remi, > > I posted on the Git ticket, but why are you talking about removing VFS? > In order for classpath scanning to work in some containers, you have to > have it. I worked with someone in IRC just a week or so ago and we got his > SpringBoot application working properly by dropping in myBatis' > SpringBootExecutableJarVFS class. No changes. It just worked. Containers > cannot be trusted to expose all of their known dependencies and classpaths > to applications for scanning purposes. That is why the VFS interfaces > exist. > > -- Rick > > On Mon, Dec 28, 2015 at 12:32 PM, VANKEISBELCK Remi <re...@rv...> wrote: > >> Hi Joaquin, >> >> Kewl ! There is no doc, but the code is pretty much the same, only a few >> mods. >> >> The key thing is to ensure that there is no regression due to the upgrade >> to servlet3. The features (async and no-vfs) are in early stage, but again, >> the big issue is regression. There's only one way to make sure it's ok : we >> need to test it as much as we can. >> >> Simplest way to do so is to rebuild the code from branch feature/async, >> and change the dependency in your Stripes app(s). Then run all your >> integration tests, and report anything broken or suspicious ! >> >> I have done this exercise on some of my Stripes apps, and found almost >> nothing. But I don't cover everything of course so the more testers, the >> better. We also need to test on various app servers to make sure. I already >> found a DMF/async bug on tomcat7 I think. >> >> Anyway, in order to build the Stripes jar : >> >> // checkout/track remote branch feature/async >> git checkout feature/async >> >> // build and run tests (unit and web - with jetty9/selenium/firefox) >> mvn clean install -Pwebtests >> >> // or with chrome (much faster, needs chromedriver.exe) >> mvn clean install -Pwebtests >> -Dwebdriver.chrome.driver=/path/to/chromedriver -Dwebtests.browser=chrome >> >> All should be green, and it should have installed the stripes jar into >> your local repo with version *1.7.0-async-SNAPSHOT*. >> >> You can then change the version of Stripes from your application and test >> everything with a servlet3 container. >> >> Thanks for your help. >> >> Cheers >> >> Rémi >> >> >> >> 2015-12-28 16:24 GMT+01:00 Joaquin Valdez <joa...@gm...>: >> >>> Hello! >>> >>> I would love to help out. Is there a doc on getting started with this? >>> Are there specific cases you would like tested? >>> >>> Thanks >>> Joaquin >>> >>> On Dec 28, 2015, at 4:54 AM, VANKEISBELCK Remi <re...@rv...> wrote: >>> >>> Hi folks, >>> >>> Merry xmas to all ! >>> >>> I'm trying to upgrade Stripes to Servlet3. >>> >>> It's required in order to fix those : >>> #35 <https://github.com/StripesFramework/stripes/issues/35> : remove >>> VFSs and let the container provide the classes to ResolverUtil >>> #37 <https://github.com/StripesFramework/stripes/issues/37> : async >>> action beans >>> >>> And anyway I think it's about time to upgrade. Servlet3 has been out for >>> a while now. >>> >>> For those interested, it's in the branch *feature/async*. Would be cool >>> to have at least a few of you guys testing this on your apps. It's quite a >>> big move, and I wouldn't want to break stuff... >>> >>> For now, I'm using Java8 and having issues with this test : >>> >>> >>> net.sourceforge.stripes.validation.ValidationWithGenericsTest#testActionBeanWithTypeParameter >>> >>> The overloads seem to cause random validation problems. I haven't digged >>> yet. Maybe someone has already had a look ? >>> >>> Cheers >>> >>> Rémi >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Stripes-development mailing list >>> Str...@li... >>> https://lists.sourceforge.net/lists/listinfo/stripes-development >>> >>> >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Stripes-development mailing list >> Str...@li... >> https://lists.sourceforge.net/lists/listinfo/stripes-development >> >> > |
From: Rick G. <rgr...@gm...> - 2015-12-29 15:11:26
|
Remi, I posted on the Git ticket, but why are you talking about removing VFS? In order for classpath scanning to work in some containers, you have to have it. I worked with someone in IRC just a week or so ago and we got his SpringBoot application working properly by dropping in myBatis' SpringBootExecutableJarVFS class. No changes. It just worked. Containers cannot be trusted to expose all of their known dependencies and classpaths to applications for scanning purposes. That is why the VFS interfaces exist. -- Rick On Mon, Dec 28, 2015 at 12:32 PM, VANKEISBELCK Remi <re...@rv...> wrote: > Hi Joaquin, > > Kewl ! There is no doc, but the code is pretty much the same, only a few > mods. > > The key thing is to ensure that there is no regression due to the upgrade > to servlet3. The features (async and no-vfs) are in early stage, but again, > the big issue is regression. There's only one way to make sure it's ok : we > need to test it as much as we can. > > Simplest way to do so is to rebuild the code from branch feature/async, > and change the dependency in your Stripes app(s). Then run all your > integration tests, and report anything broken or suspicious ! > > I have done this exercise on some of my Stripes apps, and found almost > nothing. But I don't cover everything of course so the more testers, the > better. We also need to test on various app servers to make sure. I already > found a DMF/async bug on tomcat7 I think. > > Anyway, in order to build the Stripes jar : > > // checkout/track remote branch feature/async > git checkout feature/async > > // build and run tests (unit and web - with jetty9/selenium/firefox) > mvn clean install -Pwebtests > > // or with chrome (much faster, needs chromedriver.exe) > mvn clean install -Pwebtests > -Dwebdriver.chrome.driver=/path/to/chromedriver -Dwebtests.browser=chrome > > All should be green, and it should have installed the stripes jar into > your local repo with version *1.7.0-async-SNAPSHOT*. > > You can then change the version of Stripes from your application and test > everything with a servlet3 container. > > Thanks for your help. > > Cheers > > Rémi > > > > 2015-12-28 16:24 GMT+01:00 Joaquin Valdez <joa...@gm...>: > >> Hello! >> >> I would love to help out. Is there a doc on getting started with this? >> Are there specific cases you would like tested? >> >> Thanks >> Joaquin >> >> On Dec 28, 2015, at 4:54 AM, VANKEISBELCK Remi <re...@rv...> wrote: >> >> Hi folks, >> >> Merry xmas to all ! >> >> I'm trying to upgrade Stripes to Servlet3. >> >> It's required in order to fix those : >> #35 <https://github.com/StripesFramework/stripes/issues/35> : remove >> VFSs and let the container provide the classes to ResolverUtil >> #37 <https://github.com/StripesFramework/stripes/issues/37> : async >> action beans >> >> And anyway I think it's about time to upgrade. Servlet3 has been out for >> a while now. >> >> For those interested, it's in the branch *feature/async*. Would be cool >> to have at least a few of you guys testing this on your apps. It's quite a >> big move, and I wouldn't want to break stuff... >> >> For now, I'm using Java8 and having issues with this test : >> >> >> net.sourceforge.stripes.validation.ValidationWithGenericsTest#testActionBeanWithTypeParameter >> >> The overloads seem to cause random validation problems. I haven't digged >> yet. Maybe someone has already had a look ? >> >> Cheers >> >> Rémi >> >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Stripes-development mailing list >> Str...@li... >> https://lists.sourceforge.net/lists/listinfo/stripes-development >> >> > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Stripes-development mailing list > Str...@li... > https://lists.sourceforge.net/lists/listinfo/stripes-development > > |
From: VANKEISBELCK R. <re...@rv...> - 2015-12-28 18:33:00
|
Hi Joaquin, Kewl ! There is no doc, but the code is pretty much the same, only a few mods. The key thing is to ensure that there is no regression due to the upgrade to servlet3. The features (async and no-vfs) are in early stage, but again, the big issue is regression. There's only one way to make sure it's ok : we need to test it as much as we can. Simplest way to do so is to rebuild the code from branch feature/async, and change the dependency in your Stripes app(s). Then run all your integration tests, and report anything broken or suspicious ! I have done this exercise on some of my Stripes apps, and found almost nothing. But I don't cover everything of course so the more testers, the better. We also need to test on various app servers to make sure. I already found a DMF/async bug on tomcat7 I think. Anyway, in order to build the Stripes jar : // checkout/track remote branch feature/async git checkout feature/async // build and run tests (unit and web - with jetty9/selenium/firefox) mvn clean install -Pwebtests // or with chrome (much faster, needs chromedriver.exe) mvn clean install -Pwebtests -Dwebdriver.chrome.driver=/path/to/chromedriver -Dwebtests.browser=chrome All should be green, and it should have installed the stripes jar into your local repo with version *1.7.0-async-SNAPSHOT*. You can then change the version of Stripes from your application and test everything with a servlet3 container. Thanks for your help. Cheers Rémi 2015-12-28 16:24 GMT+01:00 Joaquin Valdez <joa...@gm...>: > Hello! > > I would love to help out. Is there a doc on getting started with this? > Are there specific cases you would like tested? > > Thanks > Joaquin > > On Dec 28, 2015, at 4:54 AM, VANKEISBELCK Remi <re...@rv...> wrote: > > Hi folks, > > Merry xmas to all ! > > I'm trying to upgrade Stripes to Servlet3. > > It's required in order to fix those : > #35 <https://github.com/StripesFramework/stripes/issues/35> : remove VFSs > and let the container provide the classes to ResolverUtil > #37 <https://github.com/StripesFramework/stripes/issues/37> : async > action beans > > And anyway I think it's about time to upgrade. Servlet3 has been out for a > while now. > > For those interested, it's in the branch *feature/async*. Would be cool > to have at least a few of you guys testing this on your apps. It's quite a > big move, and I wouldn't want to break stuff... > > For now, I'm using Java8 and having issues with this test : > > > net.sourceforge.stripes.validation.ValidationWithGenericsTest#testActionBeanWithTypeParameter > > The overloads seem to cause random validation problems. I haven't digged > yet. Maybe someone has already had a look ? > > Cheers > > Rémi > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Stripes-development mailing list > Str...@li... > https://lists.sourceforge.net/lists/listinfo/stripes-development > > |
From: VANKEISBELCK R. <re...@rv...> - 2015-12-28 11:54:31
|
Hi folks, Merry xmas to all ! I'm trying to upgrade Stripes to Servlet3. It's required in order to fix those : #35 <https://github.com/StripesFramework/stripes/issues/35> : remove VFSs and let the container provide the classes to ResolverUtil #37 <https://github.com/StripesFramework/stripes/issues/37> : async action beans And anyway I think it's about time to upgrade. Servlet3 has been out for a while now. For those interested, it's in the branch *feature/async*. Would be cool to have at least a few of you guys testing this on your apps. It's quite a big move, and I wouldn't want to break stuff... For now, I'm using Java8 and having issues with this test : net.sourceforge.stripes.validation.ValidationWithGenericsTest#testActionBeanWithTypeParameter The overloads seem to cause random validation problems. I haven't digged yet. Maybe someone has already had a look ? Cheers Rémi |
From: VANKEISBELCK R. <re...@rv...> - 2015-11-17 20:34:46
|
Hi folks, I took the liberty of rewriting the webtests : I tried to run them, and they were completely outdated. I guess they are never ran... Not that they are completely exhaustive, but the mock tests are not either (eg they don't test the tag lib). Wasn't completely useless : I even found/fixed a bug in the process... For the record, the webtests were using Canoo Webtest, a browser-less framework that had its time but is now pretty much deprecated. Therefore I have re-written the tests using Selenium + Findr <https://github.com/pojosontheweb/selenium-utils> (a small utility for writing better Selenium tests, easier). The tests basically check that the Calc sample works (both old-skool and ajax versions), and tries a few things over bugzooky. One can run the tests via the IDE (they're basic junit tests), and via maven mvn clean install -Pwebtests This should run the example app inside a jetty instance, exec all tests using Firefox, and shutdown the app server. For those who prefer chrome - which is way faster (you'll need chromedriver installed locally) : mvn clean install -Pwebtests -Dwebtests.browser=chrome -Dwedriver.chrome.driver=<path_to>/chromedriver[.exe] At the time writing the tests are green. We could enable those in the continuous builds, but I'm not granted to modify the jenkins plan : https://stripesframework.ci.cloudbees.com/job/Stripes%20Master/ RickG could you please allow me ? Cheers Rémi |
From: Timothy S. <ts...@pe...> - 2015-09-01 01:46:07
|
On 8/21/15 8:15 AM, VANKEISBELCK Remi wrote: > Hi folks, > > I've played a bit with Async Support. > > I want to be able to use Servlet3's AsyncContext feature in order to > write non-blocking style Stripes actions. > ...snip... awesome preview of feature ... > > What do you guys think ? Are you interested in this feature ? I think > it's a must have today, but maybe it's just me... YES. > > I have commited my code in a "remi_async" branch, if you want to try it > out. There's also an async action example, along with the other samples, > the one that fetches commits from gh asynchronously. |
From: VANKEISBELCK R. <re...@rv...> - 2015-08-21 12:15:24
|
Hi folks, I've played a bit with Async Support. I want to be able to use Servlet3's AsyncContext feature in order to write non-blocking style Stripes actions. My use case is asynchronous, non-blocking invocation of a remote Web Service in an Action Bean's event handler, which gets the webservice response and forwards to some view : 1/ the handler is invoked 2/ it uses an async http client in order to contact a web service, passing it a callback 3/ callback is called when the web service returns 4/ action bean does some processing of the WS response 5/ view (JSP) is rendered This is not possible with Stripes out of the box : the lifecycle is implemented over the thread-per-request, synchronous model. So I wondered how we could implement this, in a simple and non-disruptive manner. The simplest solution I found was to introduce a new Resolution abstract subclass, called AsyncResolution. This one would get passed the AsyncContext, and would do whatever it needs with it, with the responsibility of completing or dispatching. You can then write an asynchronous handler like this : public Resolution myAsync() { return new AsyncResolution() { ... } } A full example that performs a request on the GitHub API : https://github.com/StripesFramework/stripes/blob/remi_async/examples/src/main/java/net/sourceforge/stripes/examples/async/AsyncActionBean.java (It's a very verbose example of course but shows how it's done) The AsyncResolution is a Resolution and has an "execute(request,response)" method. But it also has a reference to the AsyncContext that Stripes has started for us : the dispatcher now checks whether the Resolution is async or not, and starts async processing if needed, passing the AsyncContext to the resolution. Therefore, the resolution can access the AsyncContext in its execute(req,resp) method, and call asyncContext.complete() or dispatch(). I had to change the lifecycle a little bit to make this work, and also to cleanup some ThreadLocals that were never removed. The thread is basically "lost" as soon as you call request.startAsync(), so the ExecutionContext thread local leaked. Also, this approach doesn't allow for async TypeConverters, Interceptors etc. : we'd need to rewrite the whole lifecycle in order to make this work. But I don't know if it's a mandatory requirement. The main requirement for me is that I can leverage the non-blocking model when calling external web services from my controllers. What do you guys think ? Are you interested in this feature ? I think it's a must have today, but maybe it's just me... I have commited my code in a "remi_async" branch, if you want to try it out. There's also an async action example, along with the other samples, the one that fetches commits from gh asynchronously. Cheers Rémi |
From: VANKEISBELCK R. <re...@rv...> - 2015-08-12 16:22:58
|
Hi folks, As I explained in a previous email, I'm trying to make Views "statically typed" in Stripes, like Scala Templates are in Play2. I think I have something quite cool, that I'd like to share with you. Here's a draft of an "article" I wrote to explain all this : https://github.com/pojosontheweb/ttt-stripes-quickstart/blob/master/ARTICLE.md To have a look at the sources and play with the test app (java8) : git clone https://github.com/pojosontheweb/ttt-stripes-quickstart.git cd ttt-stripes-quickstart mvn jetty:run => http://localhost:8080/ It ain't production-ready yet, and lacks IDE tooling (only an IDEA plugin is available yet, and it lacks features such as refactoring, debugger etc), but it's definitely promising. A type-safe alternative to JSP. Finally. Feedback/review most appreciated. Cheers Rémi |
From: VANKEISBELCK R. <re...@rv...> - 2015-08-06 00:46:09
|
Hi Nestor, I don't know razor, but it doesn't seem to have the signature as first class citizen, like TTT does. new MyTemplate( myFoo, myBar ).render( out ); It's a huge difference. With TTT, if you change the signature of a template, then the ActionBean(s) using it will not compile. Compare this to using a jsp:forward, which ain't typesafe at all... As for JSP/Scriptlets, I'm trying to stick to JSP subset just because this way I can reuse JSP IDE tooling. It's really cool to see the completion, error reporting etc at work without actually coding anything, just associating .ttt files to JSP editor in IDEA... So I've managed to use only parts of the JSP syntax for my own needs. For example, I use the "JSP declaration" (first code-like block in template, the between <%! and %>) in order to declare the template's signature. So this template : <%! String foo; %> has 1 arg 'foo' of type String. It compiles to an immutable class with one constructor that accepts all defined arguments, and has a render() method : new MyTemplate( "hey there" ).render( out ); Cheers Rémi 2015-08-06 2:17 GMT+02:00 Nestor Hernandez <il...@gm...>: > Hey Remi. Looks good. Seems to try to emulate ASP. NET razor template. > But, seems like you're intentionally breaking rules about the use of > scriptlets. > El 5/8/2015 19:00, "VANKEISBELCK Remi" <re...@rv...> escribió: > >> Hi folks, >> >> I have managed to wrap up a 0.1-beta release for those who want to try >> out TTT templates with Stripes. >> >> The whole TTT fwk (compiler, build tools, IDE plugin) is there : >> https://github.com/pojosontheweb/ttt >> >> The Stripes integration is here : >> https://github.com/pojosontheweb/ttt/tree/master/stripes >> >> For the impatient, here's a TTT-style Calculator template >> <https://github.com/pojosontheweb/ttt/blob/master/stripes-testprj/src/main/java/stttripes/templates/CalculatorTemplate.ttt>, >> adapted from the Stripes Examples. >> >> I don't have much of the JSP tags ported yet (basically only s:form and >> s:link), but it's easier than I thought. I hope to continue with this and >> cover the whole features soon. >> >> Tell me what you think. >> >> Cheers >> >> Rémi >> >> >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Stripes-users mailing list >> Str...@li... >> https://lists.sourceforge.net/lists/listinfo/stripes-users >> >> |