Curious about WAR support

[Andy Czerwonka]

I run to many threads where people are hot and heavy lobbying for WAR support. I don't understand why WAR support is so important. Play 2 is supposed to be about the modern web. WAR is very "yesterday", or shall I say "5 years ago". What is the feature in Tomcat/Jetty/xyz that Play is missing?

[Federico Tolomei]

tl;dr
You can't simple throw away the old for the new.

A lot of businesses/work flows are based on such 'creepy' and 'old'
technologies (someone said 'SOAP', 'servlet' ?). In my case WAR
support would allow new projects (eventually made) with Play to work
along side with the 'old' and so '5 years ago' applications, reusing
as much as possible what has been made for the 'yesterday' things.

On Sat, Mar 31, 2012 at 10:17 PM, Andy Czerwonka
<andy.cz...@gmail.com> wrote:
> I run to many threads where people are hot and heavy lobbying for WAR support. I don't understand why WAR support is so important. Play 2 is supposed to be about the modern web. WAR is very "yesterday", or shall I say "5 years ago". What is the feature in Tomcat/Jetty/xyz that Play is missing?

--
skype: effe.to

[Peter Hilton - committer (Lunatech)]

Well, WAR support is required so that Play applications can be deployed in existing Java Servlet containers. Apparently, hell will freeze over before a new (Play) application can have its own JVM.

[Andy Czerwonka]

We sell software in "the Enterprise" and haven't lost a sale yet because of lack of WAR support. AFAIC, it's a useless feature and the Play team is better off focusing on useful thinks. Just my opinion.

[Erem Boto]

Anyone who wants to deploy their app on Cloudbees or amazon elastic beanstalk needs the app packaged as a war. I'm sure there are other modern environments with similar restrictions.

[MikeB]

There will always be those who cannot see beyond their own immediate
needs and discount that others may have differing situations and
requirements. Luckily the Play! committers do not operate with such
blinders in place.

[Andy Czerwonka]

+1 and there's the answer I was looking for. Makes sense.

[Andy Czerwonka]

What's your use case?

[Jaime Hablutzel Egoavil]

WAR is the packaging I know to run something in Tomcat, for example, so I think that giving war support is being more friendly to people new to the framework

On Mon, Apr 2, 2012 at 7:32 AM, Andy Czerwonka <andy.cz...@gmail.com> wrote:

What's your use case?

--
You received this message because you are subscribed to the Google Groups "play-framework" group.

To view this discussion on the web visit https://groups.google.com/d/msg/play-framework/-/9iqGNnvD0AUJ.

To post to this group, send email to play-fr...@googlegroups.com.
To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.

--
Jaime Hablutzel - 9-9956-3299
 
(tildes omitidas intencionalmente)

[Pascal Voitot Dev]

remember that you can also run play in its own JVM and then run your existing stuff in its own VM... it's not quite a problem IMHO

Pascal

[Patrick Petermair]

Consider yourself lucky then.
There are plenty of customers who have a Tomcat infrastructure setup and
no desire to change anything just because of Play. They know their
Tomcat and want a .war file.

It doesn't matter if it is a useless feature if the user / customer
wants it.

[Guillaume Bort]

The problem is not really that it is useless.

The problem is that it forces Play to adapt its whole architecture to
the WAR model: blocking IO, 1 thread per request, complicated
ClassLoader management, no complete HTTP protocol support, etc.

We are currently checking what are the impacts of providing WAR
support for Play 2.0. For now it looks like we really need JSR 340
(The servlet 3.1 specification) that provide access to NIO2 and HTTP
upgrade.

> --
> You received this message because you are subscribed to the Google Groups
> "play-framework" group.
> To post to this group, send email to play-fr...@googlegroups.com.
> To unsubscribe from this group, send email to
> play-framewor...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/play-framework?hl=en.
>

--
Guillaume Bort

[Andy Czerwonka]

It completely matters. Just because a customer wants it doesn't make it a valid case, does it? As I said in the original post, if a customer doesn't buy my service because it doesn't run in Tomcat or any other Servlet container, then I'm guessing there isn't enough value in what I created in the first place. If I did everything my customer wanted I'd have a horrible service.

I don't buy that for one second.

[Andy Czerwonka]

I know that not having WAR support in Play 2.0 is an architectural issue, I was just curious as to why it's so important. My point was for people to really ask the question "do I need it?" I'm arguing the answer in almost every case is no.

On Monday, April 2, 2012 12:20:23 PM UTC-6, Guillaume Bort wrote:

The problem is not really that it is useless.

The problem is that it forces Play to adapt its whole architecture to
the WAR model: blocking IO, 1 thread per request, complicated
ClassLoader management, no complete HTTP protocol support, etc.

We are currently checking what are the impacts of providing WAR
support for Play 2.0. For now it looks like we really need JSR 340
(The servlet 3.1 specification) that provide access to NIO2 and HTTP
upgrade.

On Mon, Apr 2, 2012 at 5:43 PM, Patrick Petermair

wrote:
> Consider yourself lucky then.
> There are plenty of customers who have a Tomcat infrastructure setup and no
> desire to change anything just because of Play. They know their Tomcat and
> want a .war file.
>
> It doesn't matter if it is a useless feature if the user / customer wants
> it.
>
>
> On 2012-04-01 04:36, Andy Czerwonka wrote:
>>
>> We sell software in "the Enterprise" and haven't lost a sale yet
>> because of lack of WAR support. AFAIC, it's a useless feature and the
>> Play team is better off focusing on useful thinks. Just my opinion.
>>
>
- 

Guillaume Bort

[Clint Gilbert]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/02/2012 11:43 AM, Patrick Petermair wrote:
> Consider yourself lucky then. There are plenty of customers who
> have a Tomcat infrastructure setup and no desire to change anything
> just because of Play. They know their Tomcat and want a .war file.

This is exactly the situation at my organization. Being able to
deploy .war files - even if it means losing some async features - will
allow us to use Play. Until then, practically speaking, we can't. :(

Note that I'm not in love with .wars, and think it's a great idea to
break away from the Servlet API, but Tomcat is what I (and I imagine
many others) have to work with.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk96FyEACgkQ5IyIbnMUeTusogCgrJsmLl+shD9pTaJUrifjyOXR
NQsAniJpy6UqXKDQKNFzwvt9/Ju153gZ
=zh31
-----END PGP SIGNATURE-----

[Andy Czerwonka]

Are you saying that someone has created policy that goes something like "Thou shalt not use any technology that does not follow the JEE Servlet specification."?

[Dominik Dorn]

On Mon, Apr 2, 2012 at 11:24 PM, Andy Czerwonka <andy.cz...@gmail.com> wrote:

Are you saying that someone has created policy that goes something like "Thou shalt not use any technology that does not follow the JEE Servlet specification."?

he probably means to say something like "I'm only allowed to use a framework which allows the _operational staff_ to easily deploy it in the already known and proven environment (tomcat, glassfish, jboss, etc... )"

its just normal business in big companies, where there are distinct departments for creating apps and for operating apps..  its always a fight and if its not easy enough, one has to take serious efforts to make it happen, e.g. beg your boss until he begs his boss so that he then tells the boss of the operating staff to get it done, even if its not the same as all the other applications already in use.

[Brian Smith]

The company I work for sell a JEE app delivered as a war to a large number of retail banks and utilities worldwide.  Every single one I've dealt with in the last five years has a centralised IT authority that have settled on a "strategic platform" of either legacy mainframe + JEE + Oracle or legacy mainframe + .Net + SQLServer.  Most of them have a large pool of third party SI guys familiar with the stack to do the work for them.

Most of their apps process or support the processing of high volume or high value financial transactions and so there is massive reluctance to step outside that (perceived) stable and low risk platform.  These guys are busily trying to homogenize their stuff because they've bought into the idea that doing so will cut risks and costs - IBM/Oracle/Microsoft etc. have sales armies full of people re-enforcing this and as the saying goes, "nobody every got fired for buying IBM".  To run something not on those stacks, they would have to have an overriding business need that could simply not be met by an app built on them.  Even price wouldn't come into it much, they'll pay more for a known quantity happily.  

I'm not suggesting Play2 should be overly bothered about deploying as a war, because frankly JEE is a cruft ridden bloated mess (try delivering the same app to run on a dozen different container/version variants!), but unfortunately not having it will hinder adoption in some areas.  Policies like the one you mention jokingly do actually exist, maybe not for the best of reasons but they're a reality.  I do agree that those lucky enough to get a choice should IMO steer well clear of JEE - it adds little of worth when offset against the costs these days.  

Cheers

Brian

[Andy Czerwonka]

I guess I am one of the lucky ones. I run a small shop of developers and we sell software. Well sell it into the Engery domain, where we do run into "corporate IT" all the time. That being said, we don't let our customers tell us how to do it. We build a product and companies buy it. Some don't, but not once have we lost a sale for non-functional reasons. Sure, they'd like us to be more "standard", but we know what "standard" really means, they don't.

[malcolm smith]

Is there some crazy architecture that would allow Play 2 to be completely embedded in TomCat that is tied to a JMX bean so that it is not at all associated with the servlet container and can answer on a raw "socket" then handle the http protocol through the native play 2.0 codebase?  The could allow deployment inside a IT-managed Tomcat infrastructure without losing the rest of Play 2.0 and provides a path forward until Servlet 3.0 provides another approach.

Yes I will lose my CTO license for even suggesting this.