Would we need to achieve better place in trends ranking?

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Would we need to achieve better place in trends ranking?

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?

Thanks in advance!

[1]: Java Tools and Technologies Landscape Report 2016: Trends and
Historical data
https://zeroturnaround.com/rebellabs/java-tools-and-technologies-landscape-2016-trends/ 


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Lukasz Lenart
2017-07-15 15:55 GMT+02:00 Yasser Zamani <[hidden email]>:
> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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 <[hidden email]>:
>> 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
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Lukasz Lenart
2017-07-17 10:49 GMT+02:00 Yasser Zamani <[hidden email]>:
> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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 <[hidden email]>:
>> 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
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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 <[hidden email]>
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 <[hidden email]>:
> >> 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] <a href="https://issues.apache.org/jira/issues/?jql=component%20%">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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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 <[hidden email]>
> 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 <[hidden email]>:
>>>> 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] <a href="https://issues.apache.org/jira/issues/?jql=component%20%">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
>>>
>>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Lukasz Lenart
In reply to this post by Yasser Zamani
2017-07-18 12:03 GMT+02:00 Yasser Zamani <[hidden email]>:
> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Support for actors/asynchronous request handling

Yasser Zamani
In reply to this post by Lukasz Lenart
To find out why and how actor model can help Struts2, I searched a lot
but just found following [1] at [2].

I wonder if you @dev have anything in your mind about: Why and how actor
model can help specifically Struts2 ? I don't mean in detail but if for
example there is a general issue exists reported by users which reminds
us the actor model. Or if for example we can run interceptors in
parallel. Or if for example we need sticky sessions in Struts2 and so so
any thought?.

Thanks in advance!
Yasser.

[1]
Stop me if you’ve heard this one. You just got off the phone with your
boss, who is getting frantic phone calls about your application throwing
errors all over the place, running extremely slowly, and in general
causing massive headaches. You check your pool of app servers, and find
that all of the threads are blocked on I/O. It’s 6am, and you haven’t
even fired up the coffee maker, and already existential dread is filling
your brain.

Java web app developers know all about this scenario— Java web
frameworks have, historically, been extremely poor at concurrency. The
number one cry of Struts or JSF developers is “just turn on sticky
sessions”, and then only a percentage of your users will get hosed when
things start going wrong at the controller level. Want to write a
controller that connects to a third-party REST service which happens to
reject a connection from time to time? Beati pauperes spiritu.

Want to asynchronously log some action to a database? Send a message to
Akka and forget about it. Want to fail gracefully when that REST service
refuses your connection? Have your Akka actor schedule the original
message to be placed back into the mailbox, and you’re done. Want to
share sessions between application servers? Ask an Akka actor to
retrieve a key from a cache, and you’re done. Want to recreate the
Quartz functionality of JBoss? Schedule an Akka actor to run every so
often with one line of code. Want to resize an image as a background
task? Send an Akka actor a message containing the bytes of the image,
return a Future containing the bytes of the resized image, and you’re done.

[2]
https://medium.com/21st-century-web-application-development/akka-the-most-important-middleware-youve-never-heard-of-dc19e386026d



On 8/1/2017 2:38 PM, Lukasz Lenart wrote:
> 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.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Support for actors/asynchronous request handling

Dave Newton-6
On Thu, Aug 17, 2017 at 10:44 AM, Yasser Zamani <[hidden email]> wrote:
> Or if for example we can run interceptors in parallel.

That would require developer knowledge since some interceptors are strictly
order-dependent. Not impossible, but would require explicit configuration.

The only real place I can see actors being helpful (without thinking hard
about it) is once the request has hit an action and the action is doing multiple
things that would be easily parallelizable, e.g., if it's hitting a
bunch of endpoints
or doing mutually-exclusive DB lookups etc.

Running requests in parallel to actors is fine, but there are already solutions
for spreading requests over cores/processes.

Shoveling off stuff like logging/analytics etc. into actors is also
fine, but I'm
not sure we'd want to put that into Struts Proper, and don't we already have
a logging layer that would allow async logging? (I don't recall.)

Dave

--
e: [hidden email]
m: 908-380-8699
s: davelnewton_skype
t: @dave_newton
b: Bucky Bits
g: davelnewton
so: Dave Newton

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Support for actors/asynchronous request handling

Christoph Nenning
In reply to this post by Yasser Zamani
>
> To find out why and how actor model can help Struts2, I searched a lot
> but just found following [1] at [2].
>
> I wonder if you @dev have anything in your mind about: Why and how actor

> model can help specifically Struts2 ? I don't mean in detail but if for
> example there is a general issue exists reported by users which reminds
> us the actor model. Or if for example we can run interceptors in
> parallel. Or if for example we need sticky sessions in Struts2 and so so

> any thought?.
>
> Thanks in advance!
> Yasser.
>

Hi,

I am not aware of specific issues or user requests.

I think of it like async servlets. Execution of action could be delegated
to some executor thread pool and execution of result (which requires tcp
connection / http response stream) must be done with some callback.

It is up to application to decide if they use async actions and which of
their actions shall be async. So if they have usecases like Dave described
(e.g. reading data from multiple backends) that would be candidates for
async actions.


Regards,
Christoph

This Email was scanned by Sophos Anti Virus
Loading...