| Re: [jakarta.ee-community] About Profiles |
That being the case, we would need to split packages into multiple JARs in order to be compatible with the Java module system, no?_______________________________________________El lun., 21 may. 2018 a las 18:39, Richard Monson-Haefel (<rmonson@xxxxxxxxxxxxx>) escribió:Right. As I understand it, You can introduce new classes under an existing javax namespace but you cannot introduce new sub-packages under the javax namespace. I think that would allow enough flexibility to break up the Servlet spec into its own base and HTTP specifications without having to introduce a new namespace.--On Mon, May 21, 2018 at 11:30 AM Werner Keil <werner.keil@xxxxxxxxx> wrote:It's not really an EG any more, those times are gone ;-) but it will be interesting to see, how e.g. making Servlet modular works under its existing namespace javax.servlet as opposed to a need for change to something else (like "ee.jakarta.servlet", etc.)I would hope that as long as certain packages or elements could be made optional it should still work under the existing namespace, while a completely new "HTTP API" some brought into the discussion, I am pretty sure this will no longer work under javax.something.Werner_______________________________________________
On Mon, May 21, 2018 at 6:24 PM, Richard Monson-Haefel <rmonson@xxxxxxxxxxxxx> wrote:+1. (Still, its fun to think of these things and discuss them out loud especially when the have an impact larger than the Servlet EG).--On Mon, May 21, 2018 at 11:21 AM Greg Wilkins <gregw@xxxxxxxxxxx> wrote:Wow,We haven't even established the Servlet EG yet and their is already talk if deprecating us:)From the jetty projects point of view, a Servlet only profile sounds like a good idea.From a Servlet EG point of view, while the Servlet API itself can be pretty lightweight, a full implementation of the Servlet spec certainly does have a bit of fat in it. So once the EG is up and running, then I'd certainly would welcome a discussion about if it is possible to have a trimmed down version of it or perhaps put a simpler layer underneath it.Cheers_______________________________________________On Mon., 21 May 2018, 15:50 reza_rahman, <reza_rahman@xxxxxxxxx> wrote:_______________________________________________This is indeed a valid argument. I would say I am OK with standardizing something like Netty or equivalent that is a level below Servlet. It may be a good idea to start that discussion with the Servlet EG. It's possible they might have an idea of how to solve this. Maybe a Servlet Core can be evolved just like CDI now has a Core.I am not too married to Servlet the API. My main point is to have something in the core that would be broadly (enough) accepted as core in the server side by the market. I think in the foreseeable future, that is something HTTP based (regardless of the threading model, flow model, etc).It is worth keeping in mind we have always had APIs that clearly belong mostly in Java EE but are not based on Servlet such as JPA or JMS (both ultimately likely TCP based). Again, it's not about raw technical merit but about market reality. To that end, while I know what you are saying, perhaps it's a bit far fetched to think Servlet would become unimportant to Java developers soon. Before deciding that's the case I would certainly want to hear what the Servlet folks think. In general I have not been disappointed in the decisions that the Servlet EG makes.Lastly, of course the core profile itself can evolve as the market shifts (if it shifts). Even if we did start with Servlet, I think it's reasonable to add an alternative model to the core as needed and even deprecate Servlet if it becomes obvious that's what should be done. Perhaps the one API to rule them all approach is also part of what we need to think differently about? Why not just acknowledge that while the core is minimal, that itself could be modular too.Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone-------- Original message --------From: James Roper <james@xxxxxxxxxxxxx>Date: 5/21/18 4:18 AM (GMT+01:00)Subject: Re: [jakarta.ee-community] About ProfilesAre servlets really necessary in the core? Yes, they may have been central to Java EE for as long as Java EE has existed, but things are changing, systems can no longer be seen is a big static state store that can just be queried and updated with synchronous communication, rather they are being build using streams, where the current state is in a constant state of converging, but never actually getting there, and communication is primarily asynchronous. Look at things like Kafka Streams and AWS Lambda and Azure Event Grid - event based systems that are only concerned with asynchronous messaging are rising rapidly in popularity at the moment. And this isn't even that new, almost 10 years ago Heroku had both web dynos and worker dynos - worker dynos had no HTTP interface, and you could argue that deploying something that started an HTTP server to a worker dyno was overkill. Now is a perfect opportunity to realign Jakarta EE with current industry trends.And even for technologies that use synchronous communication, look at the rise of things like gRPC - this does use HTTP, but not on top of servlets. No one wants to deploy both a servlet HTTP server and a gRPC server, that's too heavyweight. Other things like gRPC may well surface, do we want the servlet API to get in the way of people using these new technologies with Java EE?As a counter point against requiring servlets, the MicroProfile messaging spec currently being developed will have no dependence on servlets, and I anticipate that there will be many use cases where you'll deploy services that use nothing but MicroProfile messaging for communication, plus a database.Perhaps as little as 2 years ago, I would have agreed, servlets are core. But I think there's a big shift at the moment, and a decision to make servlets core today could leave Jakarta EE behind.On Mon, 21 May 2018 at 01:16, reza_rahman <reza_rahman@xxxxxxxxx> wrote:_______________________________________________You know I have a tremendous amount of respect for you, but as I suggested the truth is that none of this is about technical merit. Sometimes we really do need to just bow to where the market is driving us and not fight it. Once we have the technology on firmer footing is the time to explain to the marker why we are right. That's not now.The market demand from where I clearly have seen again and again is allowing people to start with Java EE with nothing more than Servlet and a la carte let them add whatever else on top. In addition there is a viable smaller market for one or two sensible profiles. Right now people also want fat jars and hollow uber jars.Giving people basically what we've been trying to push for years plus some ability to remove things or define things is yet another road to fighting another uphill battle that's honestly tiresome. The end result of where we are today should be telling us loud and clear we need to be thinking about these things differently going forward.Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone-------- Original message --------From: arjan tijms <arjan.tijms@xxxxxxxxx>Date: 5/20/18 4:40 PM (GMT+01:00)To: Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>Subject: Re: [jakarta.ee-community] About ProfilesHi,On Fri, May 18, 2018 at 11:30 PM, reza_rahman <reza_rahman@xxxxxxxxx> wrote:I am totally with Mark on these particular issues. Whatever the actual merits of the argument that we can argue endlessly, the reality is that customers cite Java EE "weight" as a reason to not adopt it with Docker/Cloud/Microservices, etc.It's true that this is being cited, although it's indeed "weight' between quotes. With only a few exceptions I've seen the actual weight (startup time / memory size / footprint on disk) of the supposedly lighter weight solution actually been approximately the same size or even bigger.People arguing that they use e.g. Tomcat because it starts in 500ms and is only 7MB in size, but then they add 50MB worth of libraries to /lib and an other 40MB of libraries to WEB-INF/lib. The combined whole being just under 100MB in disk space.As a second point, a (standard) static config + pruning tool would again address this concern, and I argue it can do even better than any profile ever can.Kind regards,ArjanAdditionally I believe other than minimizing endless conflict with Spring folks over CDI, making clear what Java EE is and how well adopted/not it is, a Servlet only core is also the right answer to combat the criticism that Java EE is fat.Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone-------- Original message --------From: Mark Little <mlittle@xxxxxxxxxx>Date: 5/18/18 3:47 PM (GMT+01:00)To: Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>Subject: Re: [jakarta.ee-community] About ProfilesOn 18 May 2018, at 14:40, arjan tijms <arjan.tijms@xxxxxxxxx> wrote:Hi,On Thu, May 17, 2018 at 1:46 PM, Mark Little <mlittle@xxxxxxxxxx> wrote:This isn’t just about vendor choice. You are certainly not alone in being happy with the full profile option. However, there are other classes of users/developers that aren’t and these have existed since the dawn of J2EE. For example, some people want to deploy their favour app server on to constrained devices which may be running on the cloud where an additional 50MB costs real money when run for hours or days or weeks or longer.I wonder, is there in practice any service / device where a mere 50MB of disk space makes all the difference?You mean apart from cloud (yes, those 1 cent costs do add up, and there’s private cloud deployments of which you may be unaware and have some funky architectural choices behind them), IoT? Oh and maybe it’s not just 50MB but some modern implementations can still be a bit “plump” in some areas ;)Some developers want to reduce the maintenance complexity or boot time of their favourite app server by stripping out those capabilities they don’t want.For that particular issue a static configuration (such as liberty's server.xml and in limited way JBoss/WildFly's standalone.xml), and/or the aforementioned prune tool would work just as well.And then we get into the world of portability. As a developer I want to know a priori that my app will work across app servers and I really don’t want to have to check when I do the migration. Having app server A and B both say they support and are compliant with Profile X is extremely useful.Now you could argue that these developers could just do this themselves anyway, e.g., JBossAS has supported this kind of pruning from the start. However, if you want portability and interoperability of your apps so you’re not tied to a specific app server implementation/vendor, having standardised profiles is the right approach.Or a standardised static config, perhaps?And what would we call those static configs. Oh hold on, let me suggest … profiles? ;)_______________________________________________Kind regards,ArjanMark.On 16 May 2018, at 23:16, Dominik Hufnagel <mail@xxxxxxxxxxxxxxxxxxx> wrote:_______________________________________________As a user of JavaEE, I do not get the idea behind having multiple profiles. May someone can explain the benefits for users? If I can have a single profile with all available features, I would take it and I do not bother using a server which is 50MB larger of one with a „smaller“ profile. I can understand that it could be harder for vendors to enter the market having to provide the full profile. But for me, this would not be an argument for using smaller profiles. I’d rather take a server from a vendor which offers me the full profile.If I would use the MicroProfile and want to have JPA, do I have to add external dependencies? I really like some of the new APIs of the MicroProfile and would be happy to see them coming to JakartaEE.
DominikVon: jakarta.ee-community-bounces@xxxxxxxxxxx [mailto:jakarta.ee-community-bounces@xxxxxxxxxxx] Im Auftrag von Mark Little
Gesendet: Mittwoch, 16. Mai 2018 11:42
An: Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>
Betreff: Re: [jakarta.ee-community] About ProfilesHopefully others have responded already but … it’s for both: quick summary … vendors so they can ensure conformance and users so they can ensure portability and interoperability of their apps.Speaking with my MicroProfile hat on, I for one would not want to trade the current MicroProfile for a full Jakarta EE profile and neither would our users.Mark.On 7 May 2018, at 17:33, arjan tijms <arjan.tijms@xxxxxxxxx> wrote:So then the first question is perhaps; who wants profiles and benefits from it? Is a profile intended for vendors or for users?---Mark LittleJBoss, by Red HatRegistered Address: Red Hat Ltd, 6700 Cork Airport Business Park, Kinsale Road, Co. Cork.
Registered in the Companies Registration Office, Parnell House, 14 Parnell Square, Dublin 1, Ireland, No.304873
Directors:Michael Cunningham (USA), Vicky Wiseman (USA), Michael O'Neill, Keith Phelan, Matt Parson (USA)
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community---Mark LittleJBoss, by Red HatRegistered Address: Red Hat Ltd, 6700 Cork Airport Business Park, Kinsale Road, Co. Cork.
Registered in the Companies Registration Office, Parnell House, 14 Parnell Square, Dublin 1, Ireland, No.304873
Directors:Michael Cunningham (USA), Vicky Wiseman (USA), Michael O'Neill, Keith Phelan, Matt Parson (USA)
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community---Mark LittleJBoss, by Red HatRegistered Address: Red Hat Ltd, 6700 Cork Airport Business Park, Kinsale Road, Co. Cork.
Registered in the Companies Registration Office, Parnell House, 14 Parnell Square, Dublin 1, Ireland, No.304873
Directors:Michael Cunningham (USA), Vicky Wiseman (USA), Michael O'Neill, Keith Phelan, Matt Parson (USA)
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community
--
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community