Re: Would we need to achieve better place in trends ranking?

[Dave Newton]

Being smaller than Spring Boot is a pretty low bar ;)

But interesting--I actually would have guessed both would be more
resource-intensive; I'm clearly behind-the-times.

On Thu, Dec 20, 2018 at 5:18 AM Johannes Geppert  wrote:

> In my first tests it looks like Struts2 is not to heavy to run as a lambda
> function.
> In fact the bundled jar is smaller than a similar Spring Boot version and
> the used memory is lower as well.
>
> See my small comparison between these both serverless solutions:
>
> https://www.jgeppert.com/2018/05/serverless-aws-lambda-performance-of-apache-struts2-vs-spring-boot/
>
> Best Regards
>
> Johannes
>
> >
> > >> Thank you. I need to explore into uSvcs to reveal if S2 need to/can be
> > >> used in such trends e.g. clouds.
> > >>
> > >
> > >"Clouds" are just servers-not-on-site. It's too heavy for serverless
> > (IMO, at least
> > >as it stands right now), and it can already be deployed on any
> reasonable
> > >infrastructure.
> >
> > Fortunately I discovered there is already a cloud plugin for Struts [1].
> >
> > Regards.
> >
>


-- 
em: davelnew...@gmail.com
mo: 908-380-8699
tw: @dave_newton 
li: dave-newton 
gh: davelnewton 
so: Dave Newton 
bl: Bucky Bits 
sk: davelnewton_skype

Re: Would we need to achieve better place in trends ranking?

[Johannes Geppert]

In my first tests it looks like Struts2 is not to heavy to run as a lambda
function.
In fact the bundled jar is smaller than a similar Spring Boot version and
the used memory is lower as well.

See my small comparison between these both serverless solutions:
https://www.jgeppert.com/2018/05/serverless-aws-lambda-performance-of-apache-struts2-vs-spring-boot/

Best Regards

Johannes

>
> >> Thank you. I need to explore into uSvcs to reveal if S2 need to/can be
> >> used in such trends e.g. clouds.
> >>
> >
> >"Clouds" are just servers-not-on-site. It's too heavy for serverless
> (IMO, at least
> >as it stands right now), and it can already be deployed on any reasonable
> >infrastructure.
>
> Fortunately I discovered there is already a cloud plugin for Struts [1].
>
> Regards.
>

RE: Would we need to achieve better place in trends ranking?

[Yasser Zamani]

>-Original Message-
>From: Dave Newton 
>Sent: Thursday, December 6, 2018 11:24 PM
>To: Struts Developers List 
>Subject: Re: Would we need to achieve better place in trends ranking?
>
>On Thu, Dec 6, 2018 at 2:44 PM Yasser Zamani 
>wrote:
>
>> Instead we may focus to facilitate "show mobile version of user web
>> app". I don't know if S2 already have such facilities e.g. via Tiles
>> or SiteMesh plugin.
>>
>
>Desktop vs. Mobile is now solidly in the realm of CSS, possibly with 
>client-side JS
>framework. S2 doesn't really try to solve those kinds of problems.
>
>If anything we could provide a responsive-first theming mechanism, but the 
>churn
>in that space makes it... problematic. A Bootstrap or Foundation theme (or 
>both)
>would be interesting, but it's a fair amount of maintenance work, and people 
>that
>are using those frameworks have things pretty well in place already (in my
>experience). Making it general-purpose enough would be tricky.

Thank you Dave. You were right that it's in the realm of CSS; and fortunately 
there is already a bootstrap and cloud plugin for Struts [1].

[1] https://github.com/struts-community-plugins

>
>
>> I also currently have no vision on those front-end trends, am exploring.
>> To be frank, something similar to Struts JQuery Plugin was my first
>> theory, however, it may be absurd.
>>
>
>Anything more complicated than jQuery will be API-driven and likely wouldn't
>need any support on the S2 side. I could see maybe exposing endpoints or
>whatever via a JS call, e.g., any of the several API documentation attempts, 
>but...
>I don't know.
>

Yes I also think API Documentation could be added to plan (like websocket) 
because I already remember a user demand for Struts-Swagger plugin [2].

[2] 
https://lists.apache.org/thread.html/fd07fec16e9a5595e117008c6ec11df924ea2f339d8fade842aff82f@%3Cdev.struts.apache.org%3E

>
>> Thank you. I need to explore into uSvcs to reveal if S2 need to/can be
>> used in such trends e.g. clouds.
>>
>
>"Clouds" are just servers-not-on-site. It's too heavy for serverless (IMO, at 
>least
>as it stands right now), and it can already be deployed on any reasonable
>infrastructure.

Fortunately I discovered there is already a cloud plugin for Struts [1].

Regards.

Re: Would we need to achieve better place in trends ranking?

[Martin Gainty]

>
>
> MG> remembering days of barosso-wannamacher regime the JS library du-jour
> >was 'sitemesh' has struts2 deprecated support for sitemesh?
>

SiteMesh had nothing to do with JS.

MG>more of an alert to JS programmers that for title/body/page.properties 
decorations can be handled by sitemesh
MG>struts-plugin
MG>




MG>FMPageFilter would process page title and body by inserting attrs into 
SimpleHash model
 model.put("title",page.getTitle());
model.put("body",page.getBody());
model.put("page.properties", new SimpleHash(page.getProperties()));
// finally, render it
template.process(model, res.getWriter());

MG>VPageFilter would insert attrs into velocity Context then render
   context.put("title",page.getTitle());
context.put("body",page.getBody());
// finally, render it
PrintWriter writer = res.getWriter();
template.merge(context, writer);
writer.flush();

MG>in the end JS coder can inject canned/customised decorator JS into their 
function with '@' sign
https://www.sitepoint.com/javascript-decorators-what-they-are/
[https://www.sitepoint.com/wp-content/themes/sitepoint/assets/images/icon.javascript.png]

JavaScript Decorators: What They Are and When to Use 
Them
In its simplest form, a decorator is simply a way of wrapping one piece of code 
with another — literally “decorating” it. This is a concept you might well have 
heard of previously as ...
www.sitepoint.com

MG>the JS coder would say I need transpiler support on my browser for 
decorating JS functions is not yet supported

MG>in that case import sitemesh-plugin from struts-2.1.6 and use fm or vm 
macros for site decoration

MG​>Future considerations:
MG>when ECMAScript gurus incorporate transpiler support for Decorator JS Code 
into ECMAscript standard
MG>and chrome,edge,safari,opera and firefox support ECMA standard that has 
transpiler support
MG>organisations that supported their-own HTML decorations (Spring/Struts)
MG> can safely deprecate their own decorators and implement JS decorations

Re: Would we need to achieve better place in trends ranking?

[Dave Newton]

>
>
> MG> remembering days of barosso-wannamacher regime the JS library du-jour
> >was 'sitemesh' has struts2 deprecated support for sitemesh?
>

SiteMesh had nothing to do with JS.

RE: Would we need to achieve better place in trends ranking?

[Yasser Zamani]

>MG>remembering days of barosso-wannamacher regime the JS library du-jour
>was 'sitemesh'
>MG>has struts2 deprecated support for sitemesh?

Hi Martin,

No not yet AFAIK. However maybe we will have to because Sitemesh seems has been 
abolished in 2015 [1]

Regards.

[1] https://github.com/sitemesh/sitemesh3/releases

-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org

Re: Would we need to achieve better place in trends ranking?

[Martin Gainty]

MG>agreed ..pls see ? below

From: Dave Newton 
Sent: Thursday, December 6, 2018 2:54 PM
To: Struts Developers List
Subject: Re: Would we need to achieve better place in trends ranking?

On Thu, Dec 6, 2018 at 2:44 PM Yasser Zamani 
wrote:

> Instead we may focus to facilitate "show mobile version of user web
> app". I don't know if S2 already have such facilities e.g. via Tiles or
> SiteMesh plugin.
>

Desktop vs. Mobile is now solidly in the realm of CSS, possibly with
client-side JS framework. S2 doesn't really try to solve those kinds of
problems.

If anything we could provide a responsive-first theming mechanism, but the
churn in that space makes it... problematic. A Bootstrap or Foundation
theme (or both) would be interesting, but it's a fair amount of maintenance
work, and people that are using those frameworks have things pretty well in
place already (in my experience). Making it general-purpose enough would be
tricky.


> I also currently have no vision on those front-end trends, am exploring.
> To be frank, something similar to Struts JQuery Plugin was my first
> theory, however, it may be absurd.
>

Anything more complicated than jQuery will be API-driven and likely
wouldn't need any support on the S2 side. I could see maybe exposing
endpoints or whatever via a JS call, e.g., any of the several API
documentation attempts, but... I don't know.

MG>remembering days of barosso-wannamacher regime the JS library du-jour was 
'sitemesh'
MG>has struts2 deprecated support for sitemesh?


> Thank you. I need to explore into uSvcs to reveal if S2 need to/can be
> used in such trends e.g. clouds.
>

"Clouds" are just servers-not-on-site. It's too heavy for serverless (IMO,
at least as it stands right now), and it can already be deployed on any
reasonable infrastructure.

d.

Re: Would we need to achieve better place in trends ranking?

[Dave Newton]

On Thu, Dec 6, 2018 at 2:44 PM Yasser Zamani 
wrote:

> Instead we may focus to facilitate "show mobile version of user web
> app". I don't know if S2 already have such facilities e.g. via Tiles or
> SiteMesh plugin.
>

Desktop vs. Mobile is now solidly in the realm of CSS, possibly with
client-side JS framework. S2 doesn't really try to solve those kinds of
problems.

If anything we could provide a responsive-first theming mechanism, but the
churn in that space makes it... problematic. A Bootstrap or Foundation
theme (or both) would be interesting, but it's a fair amount of maintenance
work, and people that are using those frameworks have things pretty well in
place already (in my experience). Making it general-purpose enough would be
tricky.


> I also currently have no vision on those front-end trends, am exploring.
> To be frank, something similar to Struts JQuery Plugin was my first
> theory, however, it may be absurd.
>

Anything more complicated than jQuery will be API-driven and likely
wouldn't need any support on the S2 side. I could see maybe exposing
endpoints or whatever via a JS call, e.g., any of the several API
documentation attempts, but... I don't know.


> Thank you. I need to explore into uSvcs to reveal if S2 need to/can be
> used in such trends e.g. clouds.
>

"Clouds" are just servers-not-on-site. It's too heavy for serverless (IMO,
at least as it stands right now), and it can already be deployed on any
reasonable infrastructure.

d.

Re: Would we need to achieve better place in trends ranking?

[Yasser Zamani]

On 12/5/2018 5:58 PM, Dave Newton wrote:
> On Wed, Dec 5, 2018 at 4:37 AM Yasser Zamani 
> wrote:
> 
>> I found dagger2 best when there are limited resources and we need an
>> urgent performance e.g. in mobile devices. But Struts unfortunately is not
>> able to be used in mobile app developments so we can postpone dagger 2 to
>> when Struts will be able.
>>
> 
> Dagger seems to be cross-platform; no reason it couldn't be used in a POJ
> project, but as you say, it seems a replacement for, not an adjunct to,
> existing DI engines. We could consider using it for internal injection
> rather than the original Guice, and allowing users to use it, but... I
> don't know. Would have to think about that and spin some PoCs.

Yes I agree. S2's internal injection cycles aren't still obvious for me
enough but why not. To compete performance we should devise to reform to
best current DI tool when is applicable.

> 
> I don't see any reason to (or even a reasonable ability to) target S2 at
> mobile.
> 

+1

Instead we may focus to facilitate "show mobile version of user web
app". I don't know if S2 already have such facilities e.g. via Tiles or
SiteMesh plugin.

> 
>> @dev wdyt? I thought what about add integration with front-end trends e.g.
>> React, Angular, Vu.js, Node.js?
> 
> 
> NodeJS isn't really front-end.
> 
> I don't know what would be added to S2 to "integrate" it into a front end;
> it already does JSON reasonably well-ish. Web socket support would be about
> the only thing "missing" in this regard.
> 

Thank you. "Web socket support" recorded :)

I also currently have no vision on those front-end trends, am exploring.
To be frank, something similar to Struts JQuery Plugin was my first
theory, however, it may be absurd.

> 
>> and improve Struts internals with concept trends e.g. microservices, DIs
>> and etc?
> 
> 
> IMO w/o some major gutting S2 won't be a (good) microservice framework.
> uSvcs are more single-function endpoints, while S2 is meant for a
> collection of endpoints. We could consider Java-based config (again/still)
> and but I'm not 100% sure what that buys the framework overall.
> 

Thank you. I need to explore into uSvcs to reveal if S2 need to/can be
used in such trends e.g. clouds.

> I should poke around a bit in the Java world again and re-familiarize
> myself with some S2 internals before saying too much, though :/

Thank you very much! As a prominent S2's member, with your advises S2
can excel and excel day by day :)

Kind regards.

Re: Would we need to achieve better place in trends ranking?

[Aleksandr Mashchenko]

> @dev wdyt? I thought what about add integration with front-end trends 
e.g. React, Angular, Vu.js, Node.js?


Node.js is not front-end.

You can use Struts with js front-ends, all you need is to serve json. 
Which can be achieved with rest or json plugin.
Speaking of which, the json plugin can be definitely improved or even 
recreated from the scratch.


> We could consider Java-based config (again/still)

Some java config stuff is already in master [1]

[1] - https://github.com/apache/struts/pull/177

---
Regards,
Aleksandr

-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org

Re: Would we need to achieve better place in trends ranking?

[Dave Newton]

On Wed, Dec 5, 2018 at 4:37 AM Yasser Zamani 
wrote:

> I found dagger2 best when there are limited resources and we need an
> urgent performance e.g. in mobile devices. But Struts unfortunately is not
> able to be used in mobile app developments so we can postpone dagger 2 to
> when Struts will be able.
>

Dagger seems to be cross-platform; no reason it couldn't be used in a POJ
project, but as you say, it seems a replacement for, not an adjunct to,
existing DI engines. We could consider using it for internal injection
rather than the original Guice, and allowing users to use it, but... I
don't know. Would have to think about that and spin some PoCs.

I don't see any reason to (or even a reasonable ability to) target S2 at
mobile.


> @dev wdyt? I thought what about add integration with front-end trends e.g.
> React, Angular, Vu.js, Node.js?


NodeJS isn't really front-end.

I don't know what would be added to S2 to "integrate" it into a front end;
it already does JSON reasonably well-ish. Web socket support would be about
the only thing "missing" in this regard.


> and improve Struts internals with concept trends e.g. microservices, DIs
> and etc?


IMO w/o some major gutting S2 won't be a (good) microservice framework.
uSvcs are more single-function endpoints, while S2 is meant for a
collection of endpoints. We could consider Java-based config (again/still)
and but I'm not 100% sure what that buys the framework overall.

I should poke around a bit in the Java world again and re-familiarize
myself with some S2 internals before saying too much, though :/

Dave

RE: Would we need to achieve better place in trends ranking?

[Yasser Zamani]

>From: Ken McWilliams 
>Sent: Wednesday, July 19, 2017 5:55 AM
>To: Struts Developers List 
>Subject: Re: Would we need to achieve better place in trends ranking?
>
>Lukasz it's good to hear the JSON plugin is on the horizon. For my own work I
>created a new JSON Result type using FlexJson, for some reason I liked it 
>better
>when serializing JPA Entities, it will by default serialize primitive types on 
>the
>object but will not travel the graph unless you explicitly tell it the 
>collections to
>traverse. Because it was the business of the action to fetch what was needed 
>(so
>it knew what needed to be
>returned) there was no issue specifying these strings. Each action had an 
>instance
>of the JSON Serializer, along with a getter for it. After setting it the way I 
>wanted,
>the result just fetched the configured instance from the action it self. It 
>didn't
>have any pretty annotations or anything but it was mindlessly simple to 
>configure
>and using the object that performed the Json serialization directly was very
>convenient.

Hi Ken, I hope this mail finds you well :)

I forgot back to you that Struts since 2.5.14 now is able to use not only 
FlexJson but also any customer specified JSON library. Please see [1] and feel 
free for any further comments.

Please follow inline comments below

>
>Yasser get the code and start making changes... no harm in doing that. I've 
>never
>seen anything but reasonableness from the struts developers if they like the
>change and it won't break things for others I'm sure they'll be happy to have 
>more
>people on team struts.
>
>MORE LESS OFF TOPIC
>Regarding keeping up with the competition: I've started a project with Spark
>framework [sparkjava.com]. It is a pretty cool framework. Struts and Spring and
>many others are in a certain vein, this thing feels a lot more like 
>development in
>Python, PHP, having a functional/imperative programming feel rather than an OO
>one... It is pretty refreshing to hardly be required to create any objects. My
>motivation was to use Dagger2 for DI, which does not work well with JEE (in a
>container environment). Dagger2 needs to be able to travel the whole graph so 
>it
>can't tolerate any "magic", other systems performing DI/reflective magic or 
>even
>using external configuration, like an xml file to determine what to 
>instantiate, so
>that eliminates a lot of web frameworks. It could still be made to work, but it
>would have to start over at each point it couldn't trace, and _you_ would have 
>to
>identify those points and work around that. All in all, not very practical.

Thanks a lot! I probed both sparkjava and dagger2 on internet via googling 
"sparkjava vs spring boot" and "dagger 2 vs spring" and reading some articles. 
I can conclude them that it seems sparkjava is best when you want to learn then 
build a "not-enterprise" web app fast. Struts but somehow is for enterprise and 
heavy wen apps. However, I agree that sparkjava's "microservices" concept must 
be added to our Struts "probe and implement" plan, thank you. I found dagger2 
best when there are limited resources and we need an urgent performance e.g. in 
mobile devices. But Struts unfortunately is not able to be used in mobile app 
developments so we can postpone dagger 2 to when Struts will be able.

>
>Any ways this thing is very different from the Java frameworks I've seen, it's 
>really
>simple, it really seems like what is going on in a lot of other languages. 
>Really at
>this point I don't know what it could bring to struts2... like adding a whole
>functional API to struts would probably be too radical.
>

@dev wdyt? I thought what about add integration with front-end trends e.g. 
React, Angular, Vu.js, Node.js? and improve Struts internals with concept 
trends e.g. microservices, DIs and etc? I think these will "make Struts great 
again" :] And make us also with Struts :)

Kind Regards.

Re: Would we need to achieve better place in trends ranking?

[Lukasz Lenart]

2017-11-10 11:35 GMT+01:00 Yasser Zamani :
> However, I thought about bring these to our maven build and github
> system. I saw this approach a few month ago with Apache commons-lang.
> When I requested a pull, I saw it fails because I don't add a @since tag
> or because I don't use {} for a one line if statement! (they have
> apache-rat:check clirr:check checkstyle:check in their maven build).
> They also comment if the PR increase or decrease the current test
> coverage [1].
>
> I am thinking about if we can add nice checkers to our maven build and
> git system little by little. The positive point is, at first place i.e.
> the PR or the commit, we block making things worse by failing the build
> if our quality metrics exceed some thresholds.
>
> I know already there are a lot of Sonar issues but maybe we can ignore
> current old ones and fail the build if new ones added at first place
> i.e. a PR or commit :)
>
> Isn't it better to resolve such issues at first place they occur? i.e.
> forcing committer or pull requester to resolve them at place. Or maybe
> you prefer to resolve newly added ones just before release in separate
> commit(s)?
>
> [1] https://github.com/apache/commons-lang/pull/261#issuecomment-289265370

Good idea, working on that :) Started with coveralls but other
improvements are welcome :)

https://github.com/apache/struts/pull/183


Regards
-- 
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org

Re: Would we need to achieve better place in trends ranking?

[Yasser Zamani]

On 11/10/2017 12:58 PM, Lukasz Lenart wrote:
> I have added a Jenkins build to perform a Sonar analysis per push but
> I disabled spamming the dev@ list for now;-)
> 
> https://builds.apache.org/analysis/overview?id=org.apache.struts%3Astruts2-parent
> 
> 2017-11-08 11:18 GMT+01:00 Lukasz Lenart:
>> There is a Sonar instance running
>> https://builds.apache.org/analysis/

Thanks! the Sonar instance seems has great analysis.

However, I thought about bring these to our maven build and github 
system. I saw this approach a few month ago with Apache commons-lang. 
When I requested a pull, I saw it fails because I don't add a @since tag 
or because I don't use {} for a one line if statement! (they have 
apache-rat:check clirr:check checkstyle:check in their maven build). 
They also comment if the PR increase or decrease the current test 
coverage [1].

I am thinking about if we can add nice checkers to our maven build and 
git system little by little. The positive point is, at first place i.e. 
the PR or the commit, we block making things worse by failing the build 
if our quality metrics exceed some thresholds.

I know already there are a lot of Sonar issues but maybe we can ignore 
current old ones and fail the build if new ones added at first place 
i.e. a PR or commit :)

Isn't it better to resolve such issues at first place they occur? i.e. 
forcing committer or pull requester to resolve them at place. Or maybe 
you prefer to resolve newly added ones just before release in separate 
commit(s)?

[1] https://github.com/apache/commons-lang/pull/261#issuecomment-289265370

Re: Would we need to achieve better place in trends ranking?

[Lukasz Lenart]

I have added a Jenkins build to perform a Sonar analysis per push but
I disabled spamming the dev@ list for now ;-)

https://builds.apache.org/analysis/overview?id=org.apache.struts%3Astruts2-parent

2017-11-08 11:18 GMT+01:00 Lukasz Lenart :
> There is a Sonar instance running
> https://builds.apache.org/analysis/
>
> 2017-11-07 19:16 GMT+01:00 Yasser Zamani :
>>
>>
>> On 7/18/2017 10:37 AM, Lukasz Lenart wrote:
>>> less static util classes and coupled code
>>
>> I started playing with JDepend [1] to see if I can have a graphical
>> anatomy of Struts :) and see if any wrong connection has been
>> established during development.
>>
>> However, it is not updated for several years but I try it; if you @dev
>> know a better tool please let me know.
>>
>> Then, I also will try if I can add CheckStyle [2] tool to unit tests
>> which I spotted during my research. Generally, I love to work on if I
>> can do something nice to also test and verify design, code, security and
>> etc qualities beside our unit tests during our continuous developments.
>> e.g. using tools like JDpend, CheckStyle, XRadar, etc.
>>
>> Also I love to see if I can run our tests in parallel to speed up things
>> at all :)
>>
>> [1] https://github.com/clarkware/jdepend
>> [2] https://github.com/checkstyle/checkstyle
>> [3] http://xradar.sourceforge.net/
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
>> For additional commands, e-mail: dev-h...@struts.apache.org
>>

-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org

Re: Would we need to achieve better place in trends ranking?

[Lukasz Lenart]

There is a Sonar instance running
https://builds.apache.org/analysis/

2017-11-07 19:16 GMT+01:00 Yasser Zamani :
>
>
> On 7/18/2017 10:37 AM, Lukasz Lenart wrote:
>> less static util classes and coupled code
>
> I started playing with JDepend [1] to see if I can have a graphical
> anatomy of Struts :) and see if any wrong connection has been
> established during development.
>
> However, it is not updated for several years but I try it; if you @dev
> know a better tool please let me know.
>
> Then, I also will try if I can add CheckStyle [2] tool to unit tests
> which I spotted during my research. Generally, I love to work on if I
> can do something nice to also test and verify design, code, security and
> etc qualities beside our unit tests during our continuous developments.
> e.g. using tools like JDpend, CheckStyle, XRadar, etc.
>
> Also I love to see if I can run our tests in parallel to speed up things
> at all :)
>
> [1] https://github.com/clarkware/jdepend
> [2] https://github.com/checkstyle/checkstyle
> [3] http://xradar.sourceforge.net/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
> For additional commands, e-mail: dev-h...@struts.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org

Re: Would we need to achieve better place in trends ranking?

[Yasser Zamani]

On 7/18/2017 10:37 AM, Lukasz Lenart wrote:
> less static util classes and coupled code

I started playing with JDepend [1] to see if I can have a graphical 
anatomy of Struts :) and see if any wrong connection has been 
established during development.

However, it is not updated for several years but I try it; if you @dev 
know a better tool please let me know.

Then, I also will try if I can add CheckStyle [2] tool to unit tests 
which I spotted during my research. Generally, I love to work on if I 
can do something nice to also test and verify design, code, security and 
etc qualities beside our unit tests during our continuous developments. 
e.g. using tools like JDpend, CheckStyle, XRadar, etc.

Also I love to see if I can run our tests in parallel to speed up things 
at all :)

[1] https://github.com/clarkware/jdepend
[2] https://github.com/checkstyle/checkstyle
[3] http://xradar.sourceforge.net/

-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org

Re: Would we need to achieve better place in trends ranking?

[Yasser Zamani]

On 7/19/2017 5:55 AM, Ken McWilliams wrote:
> Lukasz it's good to hear the JSON plugin is on the horizon. For my own work
> I created a new JSON Result type using FlexJson, for some reason I liked it
> better when serializing JPA Entities, it will by default serialize
> primitive types on the object but will not travel the graph unless you
> explicitly tell it the collections to traverse. Because it was the business
> of the action to fetch what was needed (so it knew what needed to be
> returned) there was no issue specifying these strings. Each action had an
> instance of the JSON Serializer, along with a getter for it. After setting
> it the way I wanted, the result just fetched the configured instance from
> the action it self. It didn't have any pretty annotations or anything but
> it was mindlessly simple to configure and using the object that performed
> the Json serialization directly was very convenient.

Hello Ken,

Does [1] fit your requirement? However, it is global and not every 
action but I'm interested in your opinion.

[1] http://struts.apache.org/plugins/json/#customizing-the-output

Re: Would we need to achieve better place in trends ranking?

[Christoph Nenning]

> > Are we, volunteers, allowed to help/contribute with such structural
> > changes? I hope yes. If so, I have passion in `support for
> > actors/asynchronous request handling`. Could you please register an
> > issue with a few directive details? then we can pick and start work on
> > that :) same ones for `less static util classes and coupled code` step
> > by step. (`make JSON plugin more configurable` is simple to pick, 
while
> > already has issues; `improve the framework's security` is also clear
> > enough to being considered by us).
> 
> I do not have any directives how to implement actor/async support in
> Struts2 - I thought about using http://jumi.fi/actors.html as it uses
> Apache License and it's small & fast library. I wouldn't go with Akka
> as this is a huge system by itself.
> 
> 

Jumi Actors sounds like a good way to get started with async.

Later I could imagine to have integration with akka as struts already has 
integration with big frameworks (spring). Also struts provides integration 
with different frameworks for same task (e.g. tiles and sitemesh, ...).

One step after another :)


Regards,
Christoph

This Email was scanned by Sophos Anti Virus

Re: Would we need to achieve better place in trends ranking?

[Lukasz Lenart]

2017-07-18 12:03 GMT+02:00 Yasser Zamani :
> Are we, volunteers, allowed to help/contribute with such structural
> changes? I hope yes. If so, I have passion in `support for
> actors/asynchronous request handling`. Could you please register an
> issue with a few directive details? then we can pick and start work on
> that :) same ones for `less static util classes and coupled code` step
> by step. (`make JSON plugin more configurable` is simple to pick, while
> already has issues; `improve the framework's security` is also clear
> enough to being considered by us).

I do not have any directives how to implement actor/async support in
Struts2 - I thought about using http://jumi.fi/actors.html as it uses
Apache License and it's small & fast library. I wouldn't go with Akka
as this is a huge system by itself.


Regards
-- 
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org

Re: Would we need to achieve better place in trends ranking?

[Yasser Zamani]

Thanks a lot for your share of experience (I have read it several times 
these days).

As I understand, you mention sparkjava because of it's DI (Dagger2), 
right? To understand deeper, I'll study them as soon as I had time to 
understand `what make the difference` and if Struts has a chance to 
being improved.

I also do same for FlexJson.

However, as I understand, like Lukasz, you also believe we have not much 
chance for the competition, but I think Struts will have it's users 
because of it's simple to use while powerful enough. wdyt?

On 7/19/2017 5:55 AM, Ken McWilliams wrote:
> Lukasz it's good to hear the JSON plugin is on the horizon. For my own work
> I created a new JSON Result type using FlexJson, for some reason I liked it
> better when serializing JPA Entities, it will by default serialize
> primitive types on the object but will not travel the graph unless you
> explicitly tell it the collections to traverse. Because it was the business
> of the action to fetch what was needed (so it knew what needed to be
> returned) there was no issue specifying these strings. Each action had an
> instance of the JSON Serializer, along with a getter for it. After setting
> it the way I wanted, the result just fetched the configured instance from
> the action it self. It didn't have any pretty annotations or anything but
> it was mindlessly simple to configure and using the object that performed
> the Json serialization directly was very convenient.
>
> Yasser get the code and start making changes... no harm in doing that. I've
> never seen anything but reasonableness from the struts developers if they
> like the change and it won't break things for others I'm sure they'll be
> happy to have more people on team struts.
>
> MORE LESS OFF TOPIC
> Regarding keeping up with the competition: I've started a project with
> Spark framework [sparkjava.com]. It is a pretty cool framework. Struts and
> Spring and many others are in a certain vein, this thing feels a lot more
> like development in Python, PHP, having a functional/imperative programming
> feel rather than an OO one... It is pretty refreshing to hardly be required
> to create any objects. My motivation was to use Dagger2 for DI, which does
> not work well with JEE (in a container environment). Dagger2 needs to be
> able to travel the whole graph so it can't tolerate any "magic", other
> systems performing DI/reflective magic or even using external
> configuration, like an xml file to determine what to instantiate, so that
> eliminates a lot of web frameworks. It could still be made to work, but it
> would have to start over at each point it couldn't trace, and _you_ would
> have to identify those points and work around that. All in all, not very
> practical.
>
> Any ways this thing is very different from the Java frameworks I've seen,
> it's really simple, it really seems like what is going on in a lot of other
> languages. Really at this point I don't know what it could bring to
> struts2... like adding a whole functional API to struts would probably be
> too radical.
>
>
>
>
> On Tue, Jul 18, 2017 at 4:03 AM, Yasser Zamani 
> wrote:
>
>> Great! Happy that I know these now!
>>
>> Are we, volunteers, allowed to help/contribute with such structural
>> changes? I hope yes. If so, I have passion in `support for
>> actors/asynchronous request handling`. Could you please register an
>> issue with a few directive details? then we can pick and start work on
>> that :) same ones for `less static util classes and coupled code` step
>> by step. (`make JSON plugin more configurable` is simple to pick, while
>> already has issues; `improve the framework's security` is also clear
>> enough to being considered by us).
>>
>> Ton of thanks for your time and writing for us!
>>
>> On 7/18/2017 10:37 AM, Lukasz Lenart wrote:
>>> 2017-07-17 10:49 GMT+02:00 Yasser Zamani :
 Absolutely, I did not mean you yourself should do or did something :) I
 just asked these to know if me/we, contributors, should just wait for
 user's demands in jira. or no, it's needed to analysis, study and discus
 competitors here, for new applicable (not all) features or improvements
 in Struts (e.g. you informed me that JSON and Angular are reasons so I
 can study them if any applicable feature could be added to S2).
>>>
>>> No, we should definitely not sit and wait :) Rather figure out what
>>> should be improved and what new features would be nice to have - and
>>> then code and implement them :)
>>>
>>> My two new features on the radar:
>>> - make JSON plugin more configurable, there are few issues related to it
>> [1]
>>> - add support for actors/asynchronous request handling
>>>
>>> Besides these, my main goal is to improve the framework's security and
>>> flexibility (less static util classes and coupled code).
>>>
>>> [1] https://issues.apache.org/jira/issues/?jql=component%20%
>> 

Re: Would we need to achieve better place in trends ranking?

[Ken McWilliams]

Lukasz it's good to hear the JSON plugin is on the horizon. For my own work
I created a new JSON Result type using FlexJson, for some reason I liked it
better when serializing JPA Entities, it will by default serialize
primitive types on the object but will not travel the graph unless you
explicitly tell it the collections to traverse. Because it was the business
of the action to fetch what was needed (so it knew what needed to be
returned) there was no issue specifying these strings. Each action had an
instance of the JSON Serializer, along with a getter for it. After setting
it the way I wanted, the result just fetched the configured instance from
the action it self. It didn't have any pretty annotations or anything but
it was mindlessly simple to configure and using the object that performed
the Json serialization directly was very convenient.

Yasser get the code and start making changes... no harm in doing that. I've
never seen anything but reasonableness from the struts developers if they
like the change and it won't break things for others I'm sure they'll be
happy to have more people on team struts.

MORE LESS OFF TOPIC
Regarding keeping up with the competition: I've started a project with
Spark framework [sparkjava.com]. It is a pretty cool framework. Struts and
Spring and many others are in a certain vein, this thing feels a lot more
like development in Python, PHP, having a functional/imperative programming
feel rather than an OO one... It is pretty refreshing to hardly be required
to create any objects. My motivation was to use Dagger2 for DI, which does
not work well with JEE (in a container environment). Dagger2 needs to be
able to travel the whole graph so it can't tolerate any "magic", other
systems performing DI/reflective magic or even using external
configuration, like an xml file to determine what to instantiate, so that
eliminates a lot of web frameworks. It could still be made to work, but it
would have to start over at each point it couldn't trace, and _you_ would
have to identify those points and work around that. All in all, not very
practical.

Any ways this thing is very different from the Java frameworks I've seen,
it's really simple, it really seems like what is going on in a lot of other
languages. Really at this point I don't know what it could bring to
struts2... like adding a whole functional API to struts would probably be
too radical.




On Tue, Jul 18, 2017 at 4:03 AM, Yasser Zamani 
wrote:

> Great! Happy that I know these now!
>
> Are we, volunteers, allowed to help/contribute with such structural
> changes? I hope yes. If so, I have passion in `support for
> actors/asynchronous request handling`. Could you please register an
> issue with a few directive details? then we can pick and start work on
> that :) same ones for `less static util classes and coupled code` step
> by step. (`make JSON plugin more configurable` is simple to pick, while
> already has issues; `improve the framework's security` is also clear
> enough to being considered by us).
>
> Ton of thanks for your time and writing for us!
>
> On 7/18/2017 10:37 AM, Lukasz Lenart wrote:
> > 2017-07-17 10:49 GMT+02:00 Yasser Zamani :
> >> Absolutely, I did not mean you yourself should do or did something :) I
> >> just asked these to know if me/we, contributors, should just wait for
> >> user's demands in jira. or no, it's needed to analysis, study and discus
> >> competitors here, for new applicable (not all) features or improvements
> >> in Struts (e.g. you informed me that JSON and Angular are reasons so I
> >> can study them if any applicable feature could be added to S2).
> >
> > No, we should definitely not sit and wait :) Rather figure out what
> > should be improved and what new features would be nice to have - and
> > then code and implement them :)
> >
> > My two new features on the radar:
> > - make JSON plugin more configurable, there are few issues related to it
> [1]
> > - add support for actors/asynchronous request handling
> >
> > Besides these, my main goal is to improve the framework's security and
> > flexibility (less static util classes and coupled code).
> >
> > [1] https://issues.apache.org/jira/issues/?jql=component%20%
> 3D%20%22Plugin%20-%20JSON%22%20AND%20project%20%3D%20WW%
> 20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC
> >
> >
> > Regards
> >
>



-- 
Sent from my C64 using a 300 baud modem

Re: Would we need to achieve better place in trends ranking?

[Yasser Zamani]

Great! Happy that I know these now!

Are we, volunteers, allowed to help/contribute with such structural 
changes? I hope yes. If so, I have passion in `support for 
actors/asynchronous request handling`. Could you please register an 
issue with a few directive details? then we can pick and start work on 
that :) same ones for `less static util classes and coupled code` step 
by step. (`make JSON plugin more configurable` is simple to pick, while 
already has issues; `improve the framework's security` is also clear 
enough to being considered by us).

Ton of thanks for your time and writing for us!

On 7/18/2017 10:37 AM, Lukasz Lenart wrote:
> 2017-07-17 10:49 GMT+02:00 Yasser Zamani :
>> Absolutely, I did not mean you yourself should do or did something :) I
>> just asked these to know if me/we, contributors, should just wait for
>> user's demands in jira. or no, it's needed to analysis, study and discus
>> competitors here, for new applicable (not all) features or improvements
>> in Struts (e.g. you informed me that JSON and Angular are reasons so I
>> can study them if any applicable feature could be added to S2).
>
> No, we should definitely not sit and wait :) Rather figure out what
> should be improved and what new features would be nice to have - and
> then code and implement them :)
>
> My two new features on the radar:
> - make JSON plugin more configurable, there are few issues related to it [1]
> - add support for actors/asynchronous request handling
>
> Besides these, my main goal is to improve the framework's security and
> flexibility (less static util classes and coupled code).
>
> [1] 
> https://issues.apache.org/jira/issues/?jql=component%20%3D%20%22Plugin%20-%20JSON%22%20AND%20project%20%3D%20WW%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC
>
>
> Regards
>

Re: Would we need to achieve better place in trends ranking?

[Lukasz Lenart]

2017-07-17 10:49 GMT+02:00 Yasser Zamani :
> Absolutely, I did not mean you yourself should do or did something :) I
> just asked these to know if me/we, contributors, should just wait for
> user's demands in jira. or no, it's needed to analysis, study and discus
> competitors here, for new applicable (not all) features or improvements
> in Struts (e.g. you informed me that JSON and Angular are reasons so I
> can study them if any applicable feature could be added to S2).

No, we should definitely not sit and wait :) Rather figure out what
should be improved and what new features would be nice to have - and
then code and implement them :)

My two new features on the radar:
- make JSON plugin more configurable, there are few issues related to it [1]
- add support for actors/asynchronous request handling

Besides these, my main goal is to improve the framework's security and
flexibility (less static util classes and coupled code).

[1] 
https://issues.apache.org/jira/issues/?jql=component%20%3D%20%22Plugin%20-%20JSON%22%20AND%20project%20%3D%20WW%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC


Regards
-- 
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org

Re: Would we need to achieve better place in trends ranking?

[Yasser Zamani]

Thank you very much!

I have no experience with Spring MVC and JSF so far. So unfortunately I 
do not know about it's major release migrations. I also have no idea why 
it is in more usage :/

Absolutely, I did not mean you yourself should do or did something :) I 
just asked these to know if me/we, contributors, should just wait for 
user's demands in jira. or no, it's needed to analysis, study and discus 
competitors here, for new applicable (not all) features or improvements 
in Struts (e.g. you informed me that JSON and Angular are reasons so I 
can study them if any applicable feature could be added to S2).

Sincerely Yours,
Yasser.

On 7/17/2017 11:42 AM, Lukasz Lenart wrote:
> 2017-07-15 15:55 GMT+02:00 Yasser Zamani :
>> Hi there,
>>
>> This is a 2016 trend of Web Framework Usages from [1].
>> java-web-frameworks-usage-trends
>>
>> I would like to know if we need an analysis of why S2 is number 4 in
>> ranking? If so, then we can plan for enhancements and new features to
>> achieve better place in ranking, right? What's your idea please?
>
> From my point of view, Spring MVC is mostly used to create a JSON API
> to be used with Single Page Apps, i.e. Angular - the most (over?)used
> approach to create web apps these days. If you want to use Struts to
> do the same you are getting a lot of overhead (support for JSPs,
> Freemarker, EL, etc) bundled into a one jar.
>
> Also Struts still isn't so well structured as Spring (but I'm working
> hard on that ;-) and isn't supported by a company that makes money on
> it ;-)
>
> Anyway, I don't think we can compete with Spring, we should focus on
> what should be done and fixed - that's all. I'm also curious how hard
> is to migrate between each major release of Spring?
>
>
> Regards
>

Re: Would we need to achieve better place in trends ranking?

[Lukasz Lenart]

2017-07-15 15:55 GMT+02:00 Yasser Zamani :
> Hi there,
>
> This is a 2016 trend of Web Framework Usages from [1].
> java-web-frameworks-usage-trends
>
> I would like to know if we need an analysis of why S2 is number 4 in
> ranking? If so, then we can plan for enhancements and new features to
> achieve better place in ranking, right? What's your idea please?

>From my point of view, Spring MVC is mostly used to create a JSON API
to be used with Single Page Apps, i.e. Angular - the most (over?)used
approach to create web apps these days. If you want to use Struts to
do the same you are getting a lot of overhead (support for JSPs,
Freemarker, EL, etc) bundled into a one jar.

Also Struts still isn't so well structured as Spring (but I'm working
hard on that ;-) and isn't supported by a company that makes money on
it ;-)

Anyway, I don't think we can compete with Spring, we should focus on
what should be done and fixed - that's all. I'm also curious how hard
is to migrate between each major release of Spring?


Regards
-- 
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org