Re: Jakarta EE 9
Am 2019-10-28 um 22:00 schrieb Stefan Mayr: Am 28.10.2019 um 14:13 schrieb Rémy Maucherat: On Mon, Oct 28, 2019 at 1:46 PM Johan Compagner wrote: Hi On Mon, 28 Oct 2019 at 13:15, Mark Thomas wrote: Hi all, A frequent topic of discussion at ApacheCon EU was Jakarta EE 9. For those of you who aren't familiar with Jakarta EE the key points are: - Oracle have donated Java EE to Eclipse - Eclipse have released Jakarta EE 8 which is essentially identical to Java EE 8 - Oracle have refused to allow changes to the APIs in the javax namespace - The Jakarta EE community seem to be reaching consensus on releasing Jakarta EE 9 which will rename all the Java packages from javax.* to jakarta.* what does this rename really mean? import javax.servlet.http.HttpSession; import javax.websocket.Session; those are renamed? If that is yes that would mean pretty much everything will break? https://eclipse-foundation.blog/2019/05/03/jakarta-ee-java-trademarks/ I thought everyone knew about this. We were supposed to have a session on this rename at ApacheCon EU, but unfortunately it didn't happen. Rémy This article mentions that javax.* package namespace is not allowed to change. The API needs to remain compatible. When javax.* is renamed to jakarta.* it should be sufficient to have a javax.* shim library that translates everything to use jakarta.*. Or is there any public information that Oracle prohibits that too? This will only work if the API won't change. I consider such a shim to be dangerous at some point in time. Michael - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Jakarta EE 9
Am 28.10.2019 um 14:13 schrieb Rémy Maucherat: > On Mon, Oct 28, 2019 at 1:46 PM Johan Compagner > wrote: > >> Hi >> >> >> >> On Mon, 28 Oct 2019 at 13:15, Mark Thomas wrote: >> >>> Hi all, >>> >>> A frequent topic of discussion at ApacheCon EU was Jakarta EE 9. For >> those >>> of you who aren't familiar with Jakarta EE the key points are: >>> >>> - Oracle have donated Java EE to Eclipse >>> - Eclipse have released Jakarta EE 8 which is essentially identical to >>> Java EE 8 >>> - Oracle have refused to allow changes to the APIs in the javax namespace >>> - The Jakarta EE community seem to be reaching consensus on releasing >>> Jakarta EE 9 which will rename all the Java packages from javax.* to >>> jakarta.* >>> >>> >> >> what does this rename really mean? >> >> import javax.servlet.http.HttpSession; >> import javax.websocket.Session; >> >> those are renamed? >> If that is yes that would mean pretty much everything will break? >> > > https://eclipse-foundation.blog/2019/05/03/jakarta-ee-java-trademarks/ > I thought everyone knew about this. We were supposed to have a session on > this rename at ApacheCon EU, but unfortunately it didn't happen. > > Rémy > This article mentions that javax.* package namespace is not allowed to change. The API needs to remain compatible. When javax.* is renamed to jakarta.* it should be sufficient to have a javax.* shim library that translates everything to use jakarta.*. Or is there any public information that Oracle prohibits that too? Regards, Stefan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Jakarta EE 9
On Mon, Oct 28, 2019 at 3:53 PM i...@flyingfischer.ch wrote: > Am 28.10.19 um 15:39 schrieb Mark Thomas > >> If this is going to be disruptive and we cannot maintain compat, why > >> not > >> go the extra step and explicitly move Tomcat code to > >> org.apache.tomcat.* > >> for Tomcat 10? Git renames will work flawlessly for backports. > > It will break things for users that code against those APIs. It is a > small number but some do. > > > > Mark > Do you have any evidence based number on this matter? May be in turns > oout that this "small number" isn't as small as assumed... > > Of course, it's actually rather huge: - Anyone using Tomcat embedded - Anyone having written a custom Catalina component - Anyone using a library with a Tomcat integration - Anyone using a framework that embeds Tomcat The rationale is that the jakarta change is already breaking compatibility, and thus to go all in. But I don't share that opinion, it's simply easier to explain to users that there's a single change: rename javax.servlet (and the others) to jakarta.servlet. Plus there might be tools or deployment tricks to do that magically in most cases, while there would likely be nothing for Tomcat package changes. Rémy
Re: Jakarta EE 9
On October 28, 2019 2:53:29 PM UTC, "i...@flyingfischer.ch" wrote: >Am 28.10.19 um 15:39 schrieb Mark Thomas >>> If this is going to be disruptive and we cannot maintain compat, why >>> not >>> go the extra step and explicitly move Tomcat code to >>> org.apache.tomcat.* >>> for Tomcat 10? Git renames will work flawlessly for backports. >> It will break things for users that code against those APIs. It is a >small number but some do. >> >> Mark >Do you have any evidence based number on this matter? May be in turns >oout that this "small number" isn't as small as assumed... Only a sense based on experience of issues raised when we have previously changed the internal API - usually between major versions. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Jakarta EE 9
Am 28.10.19 um 15:39 schrieb Mark Thomas >> If this is going to be disruptive and we cannot maintain compat, why >> not >> go the extra step and explicitly move Tomcat code to >> org.apache.tomcat.* >> for Tomcat 10? Git renames will work flawlessly for backports. > It will break things for users that code against those APIs. It is a small > number but some do. > > Mark Do you have any evidence based number on this matter? May be in turns oout that this "small number" isn't as small as assumed... Markus - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Jakarta EE 9
On Mon, Oct 28, 2019 at 3:11 PM Michael Osipov wrote: > Am 2019-10-28 um 14:59 schrieb Mark Thomas: > > On October 28, 2019 12:37:14 PM UTC, Johan Compagner < > jcompag...@servoy.com> wrote: > >> Hi > >> > >> > >> > >> On Mon, 28 Oct 2019 at 13:15, Mark Thomas wrote: > >> > >>> Hi all, > >>> > >>> A frequent topic of discussion at ApacheCon EU was Jakarta EE 9. For > >> those > >>> of you who aren't familiar with Jakarta EE the key points are: > >>> > >>> - Oracle have donated Java EE to Eclipse > >>> - Eclipse have released Jakarta EE 8 which is essentially identical > >> to > >>> Java EE 8 > >>> - Oracle have refused to allow changes to the APIs in the javax > >> namespace > >>> - The Jakarta EE community seem to be reaching consensus on releasing > >>> Jakarta EE 9 which will rename all the Java packages from javax.* to > >>> jakarta.* > >>> > >>> > >> > >> what does this rename really mean? > >> > >> import javax.servlet.http.HttpSession; > >> import javax.websocket.Session; > >> > >> those are renamed? > >> If that is yes that would mean pretty much everything will break? > > > > Correct. Hence the question on options for how we consider maintaining > compatibility. > > If this is going to be disruptive and we cannot maintain compat, why not > go the extra step and explicitly move Tomcat code to org.apache.tomcat.* > for Tomcat 10? Git renames will work flawlessly for backports. > > I assume that most users never knew or don't understand where "catalina" > comes from. > There's no reason to break APIs just for the sake of it (and the current package structure looks relatively reasonable to me, catalina is the actual container, coyote is the connector, jasper is Jasper). This is really like "oh, this is going to be a pain for users, so while we're at it let's destroy the rest". At this point I think the differences with the current 9 should be as limited as possible to avoid user problems. If more significant items get included such as, let's say, APR removal or some similar feature that wouldn't be backported to 9, then it should be limited to these items and it justifies the branch being called "10" rather than "9.something". Rémy
Re: Jakarta EE 9
On October 28, 2019 2:11:22 PM UTC, Michael Osipov wrote: >Am 2019-10-28 um 14:59 schrieb Mark Thomas: >> On October 28, 2019 12:37:14 PM UTC, Johan Compagner > wrote: >>> Hi >>> >>> >>> >>> On Mon, 28 Oct 2019 at 13:15, Mark Thomas wrote: >>> Hi all, A frequent topic of discussion at ApacheCon EU was Jakarta EE 9. >For >>> those of you who aren't familiar with Jakarta EE the key points are: - Oracle have donated Java EE to Eclipse - Eclipse have released Jakarta EE 8 which is essentially identical >>> to Java EE 8 - Oracle have refused to allow changes to the APIs in the javax >>> namespace - The Jakarta EE community seem to be reaching consensus on >releasing Jakarta EE 9 which will rename all the Java packages from javax.* >to jakarta.* >>> >>> what does this rename really mean? >>> >>> import javax.servlet.http.HttpSession; >>> import javax.websocket.Session; >>> >>> those are renamed? >>> If that is yes that would mean pretty much everything will break? >> >> Correct. Hence the question on options for how we consider >maintaining compatibility. > >If this is going to be disruptive and we cannot maintain compat, why >not >go the extra step and explicitly move Tomcat code to >org.apache.tomcat.* >for Tomcat 10? Git renames will work flawlessly for backports. It will break things for users that code against those APIs. It is a small number but some do. Mark > >I assume that most users never knew or don't understand where >"catalina" >comes from. > >Michael > >- >To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: JSP custom tag operating different when adoptOpenJDK is used vs Oracle (cross post from tomcat-taglibs-user)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Jeff,
On 10/28/19 09:31, LoBello,Jeff wrote:
> That’s good to hear, you’re example works. In our tag class, which
> extends
> org.apache.taglibs.standard.tag.common.fmt.FormatDateSupport, we
> have setValue() overloaded, as follows…
>
>
> public void setValue(final String value) {
>
>
>
> public void setValue(final Object value) {
>
> Is this a bad practice? How does tomcat decide which one to use.
> Why would changing to adoptOpenJdk break this?
My guess is that Tomcat is not following some edge-case of the
specification, and that when you use the AdoptJDK JVM, the methods
from Class.getDeclaredMethod are being returned in a slightly
different order, and Tomcat picks a different method.
Just a guess. But, it *should* be consistent across JVMs.
- -chris
> From: Felix Schumacher
> Reply-To: Tomcat Users List Date: Sunday,
> October 27, 2019 at 2:52 PM To: "users@tomcat.apache.org"
> Subject: Re: JSP custom tag operating
> different when adoptOpenJDK is used vs Oracle (cross post from
> tomcat-taglibs-user)
>
> I tried to reproduce the bug with the following simple jsp:
>
> <%@ taglib prefix = "fmt" uri =
> "https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fjava
.sun.com%2Fjsp%2Fjstl%2Ffmtdata=02%7C01%7CJeff.Lobello%40cerner.com
%7C37f57f209f8d4449bcf508d75b0ed587%7Cfbc493a80d244454a815f4ca58e8c09d%7
C0%7C1%7C637077991639831717sdata=PIygTHb1ENhnrEL9v8oZYTGMyzUJfwd0GN
Ufz5xMEMM%3Dreserved=0"
> %>
>
> String/Object bug
>
> <% request.setAttribute("now", new java.util.Date()); %>
>
>
>
> but both Java versions (oracle 1.8.0_201 and openjdk 1.8.0_222)
> produce the following java parts with tomcat 9.0.27:
>
> ... // /index.jsp(12,6) name = value type = null reqTime = true
> required = true fragment = false deferredValue = false
> expectedTypeName = null deferredMethod = false methodSignature =
> null _jspx_th_fmt_005fformatDate_005f0.setValue((java.util.Date)
> org.apache.jasper.runtime.PageContextImpl.proprietaryEvaluate("${now}"
,
>
>
java.util.Date.class, (javax.servlet.jsp.PageContext)_jspx_page_context,
> null)); ...
>
> Can you share your tag implementation or even better give us a
> minimal webapp that shows the error?
>
> Is the Tomcat version the same for the different Java
> implementations?
>
> Felix
>
> Am 27.10.19 um 18:14 schrieb LoBello,Jeff: Sorry for not mentioning
> that before, Felix. I’ve seen this bug under Mac & Windows Java
> versions. We only support Java 1.8, at the moment.
>
>
> Mac:
>
> openjdk version "1.8.0_222"
>
> OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_222-b10)
>
> OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.222-b10, mixed
> mode)
>
>
>
> Windows:
>
> openjdk version "1.8.0_192"
>
> OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_192-b12)
>
> OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.192-b12, mixed
> mode)
>
> We’ve also reproduced this issue with multiple Tomcat versions,
> including 7, 8 & 9. If we use Oracle Java, the issue is fixed &
> doesn’t happen. The bug is very subtle since the JSP does compile,
> but the data passed to our tag is a String instead of a Date
> object.
>
> Thanks,
>
> Jeff LoBello Lead Software Engineer Cerner |
> www.cerner.com>:
>
>
We have a custom tag, FormatDateTag extends
> org.apache.taglibs.standard.tag.common.fmt.FormatDateSupport.
> It’s been working ok for a number of years under tomcat & Oracle
> JVM. Now, we are moving to adoptOpenJDK & we are seeing some
> differences in how tomcat generation of JSP to Java classes happens
> when tomcat is doing the EL evaluation. Here is an example JSP
> which shows the issue…
>
> Which Java versions have you used exactly? What os was this? Which
> tomcat version have you used?
>
> Are there any other differences in the setup?
>
> Felix
>
>
> <%@ page language="java" contentType="text/html"
> isELIgnored="false" %> <%@ page import="java.util.Date" %> <%@
> taglib uri="/WEB-INF/tld/suitags.tld" prefix="sui" %>
>
> <% Date chdt = new Date(); request.setAttribute("chdt", chdt); %>
>
> />
>
> Looking at the compiled JSP source code under Oracle JVM, we see
> this…
>
> // /tagUnitTests/sui/formatDate/testCaliHDateTime1.jsp(20,0) name
> = value type = java.lang.Object reqTime = true required = true
> fragment = false deferredValue = false expectedTypeName = null
>
Re: Jakarta EE 9
On Mon, Oct 28, 2019 at 1:15 PM Mark Thomas wrote: > Hi all, > > A frequent topic of discussion at ApacheCon EU was Jakarta EE 9. For those > of you who aren't familiar with Jakarta EE the key points are: > > - Oracle have donated Java EE to Eclipse > - Eclipse have released Jakarta EE 8 which is essentially identical to > Java EE 8 > - Oracle have refused to allow changes to the APIs in the javax namespace > - The Jakarta EE community seem to be reaching consensus on releasing > Jakarta EE 9 which will rename all the Java packages from javax.* to > jakarta.* > - Jakarta EE 9 will not contain any other API changes > - It will be a requirement to maintain backwards comparability (maybe not > 100% compatibility) with Jakarta EE 8 > - Jakarta EE 9 will be released in the next ~11 months > - Jakarta EE 10 will then follow which is where new features will be > introduced > > This raises various questions for the Tomcat community including: > > 1. Do we implement Jakarta EE 9? > > Assuming yes to q1. > +0.1 > > 2. As Tomcat 10 or some other version? > I'm not convinced yet by using 10 for that since EE 9 is functionally equivalent. > > 3. How do we manage development (in a branch, as master, ...)? > I would say master. > > 4. How do we implement backwards compatability? Runtime, deploy time, > compilation time? > I have no idea how this would realistically be achieved at the moment. To run on jakarta, the most problematic are libraries and frameworks and it seems difficult to me to think it is really possible to hack our way in at runtime. Deployment, I don't know, so you seem to believe BCEL is a possibility. > > 5. At what point do we EOL Tomcat 7? (since Jakarta EE 9 is just a package > renaming?) > We should mandate that, except for the jakarta package rename changes and/or functionality, all commits to that master should be backported to 9.0 (no exceptions). Keeping 7 is possible, but it means more work. > > 6. Do we commit to supporting Tomcat 9 for an extended period? (to provide > a version that supports java.* directly) > I would be in favor of that as a mirror of that new branch, since it would be hard to guarantee zero issues for "legacy" javax.* webapps, which will basically continue to exist forever. > > I'm posting this to users@ as how Tomcat users want to use and adopt > Jakarta EE 9 is likely to be the biggest driving factor in choosing answers > to these questions. > > We don't have to have all of the answers right now. I think we do need > answers for 1 & 3 so we can start. A few options and 'wait and see' is > likely good enough for the rest for now. > > I have my own views on the answers but I have tried not to express them > here so we can get as wide a discussion as possible. > > Thoughts? > Rémy
Re: Jakarta EE 9
Am 2019-10-28 um 14:59 schrieb Mark Thomas: On October 28, 2019 12:37:14 PM UTC, Johan Compagner wrote: Hi On Mon, 28 Oct 2019 at 13:15, Mark Thomas wrote: Hi all, A frequent topic of discussion at ApacheCon EU was Jakarta EE 9. For those of you who aren't familiar with Jakarta EE the key points are: - Oracle have donated Java EE to Eclipse - Eclipse have released Jakarta EE 8 which is essentially identical to Java EE 8 - Oracle have refused to allow changes to the APIs in the javax namespace - The Jakarta EE community seem to be reaching consensus on releasing Jakarta EE 9 which will rename all the Java packages from javax.* to jakarta.* what does this rename really mean? import javax.servlet.http.HttpSession; import javax.websocket.Session; those are renamed? If that is yes that would mean pretty much everything will break? Correct. Hence the question on options for how we consider maintaining compatibility. If this is going to be disruptive and we cannot maintain compat, why not go the extra step and explicitly move Tomcat code to org.apache.tomcat.* for Tomcat 10? Git renames will work flawlessly for backports. I assume that most users never knew or don't understand where "catalina" comes from. Michael - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Jakarta EE 9
On October 28, 2019 1:11:46 PM UTC, Christopher Schultz wrote: >-BEGIN PGP SIGNED MESSAGE- >Hash: SHA256 > >Mark, > >On 10/28/19 08:15, Mark Thomas wrote: >> Hi all, >> >> A frequent topic of discussion at ApacheCon EU was Jakarta EE 9. >> For those of you who aren't familiar with Jakarta EE the key points >> are: >> >> - Oracle have donated Java EE to Eclipse - Eclipse have released >> Jakarta EE 8 which is essentially identical to Java EE 8 - Oracle >> have refused to allow changes to the APIs in the javax namespace - >> The Jakarta EE community seem to be reaching consensus on releasing >> Jakarta EE 9 which will rename all the Java packages from javax.* >> to jakarta.* - Jakarta EE 9 will not contain any other API changes >> - It will be a requirement to maintain backwards comparability >> (maybe not 100% compatibility) with Jakarta EE 8 - Jakarta EE 9 >> will be released in the next ~11 months - Jakarta EE 10 will then >> follow which is where new features will be introduced >> >> This raises various questions for the Tomcat community including: >> >> 1. Do we implement Jakarta EE 9? >> >> Assuming yes to q1. >> >> 2. As Tomcat 10 or some other version? >> >> 3. How do we manage development (in a branch, as master, ...)? >> >> 4. How do we implement backwards compatability? Runtime, deploy >> time, compilation time? >> >> 5. At what point do we EOL Tomcat 7? (since Jakarta EE 9 is just a >> package renaming?) >> >> 6. Do we commit to supporting Tomcat 9 for an extended period? (to >> provide a version that supports java.* directly) >> >> I'm posting this to users@ as how Tomcat users want to use and >> adopt Jakarta EE 9 is likely to be the biggest driving factor in >> choosing answers to these questions. >> >> We don't have to have all of the answers right now. I think we do >> need answers for 1 & 3 so we can start. A few options and 'wait and >> see' is likely good enough for the rest for now. >> >> I have my own views on the answers but I have tried not to express >> them here so we can get as wide a discussion as possible. > >How "simple" of a replacement are we talking about, here? For example, >can it be done simply with sed? Probably not. JSPs are likely to be more complicated. The XSDs are probably not an issue. Request attributes and similar may need to support both javax.* and jakarta.* names for attributes. The detail is TBD. >$ find . -type f | xargs sed -e 's/javax.servlet/jakarta.servlet/g' > >? > >I'm asking because if it really is that easy, then we should be able >to trivially package each of the existing Tomcat 7, 8.5, 9 releases as >7.jakarta, 8.5.jakarta, and 9.jakarta alongside their legacy Java EE >versions. That only works if users can have separate Tomcat instances for javax.* based apps and jakarta.* based apps. My sense is that that will not be an acceptable option for all users. >Users wanting to move to the Jakarta EE namespace can do so with >existing, reliable versions of Tomcat instead of waiting for Tomcat 10 >or Tomcat having to implement some kind of hybrid version which >supports BOTH flavors of APIs (which seems kind of nightmarish to me). A runtime solution to compatibility would not be my first choice. I'm currently learning towards a BCEL based solution(or simikar) at deployment time. >Are there any restrictions against us supporting Jakarta EE in >existing Tomcat releases? Naming could be an issue. There might also be some very minor API changes as well as the package rename. That would make that tricky. Mark > I don't believe so. We merely advertise >support for various standards; Tomcat is no longer the "reference >implementation" of any APIs so we can do whatever we want, right? > >If we do a simply sed-style re-naming of packages to produce parallel >releases, will they actually work? My sense is that, yes, they will >indeed work. > >- -chris >-BEGIN PGP SIGNATURE- >Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > >iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl226RIACgkQHPApP6U8 >pFjnfQ//bYExvm+BEhwroa/W+v3BGx+Bw0qtzz9MxjDIZ1zcGuxlITb1QdoYZ1sz >C9eQumSo/gK1sO8ImVhMCYdFOf1n2az/olcMdF2v9gYC3YMZ11+qQhppYRxvfRvG >pHzkV4PHbE6mgvfY9pli6LBs1Na1MSN0nRLluC4OBz3wMGCLQyByfBX3x+++8klB >HHM1wcJDLzziIBmM3NKcuEFQ1gVbjlV10rFYes29KiuG4z78FRPY87pQmP+Xj71o >l5NEtERYA+SjDGPZo6wrF6k3l23cZL/yrCp4PGwO1c0VB148DervvWG33+9OEOQL >1E8F0IZc2o2eiNYUxbUQcMxGXORnfbWpMyG8RVSVlwdhmzO4Ug1pxNVcpO2Y2qC2 >vHHz+deQiQ/dZIsNU5aWtC+MBL7tx3RWxBNxb3n2d5T9tJm6zHBSdGfcPyTN14cV >HTtPj9al4usxoT3XGSEhAP7FiI1RJXywq+o0sppaF6BrAh0UpRIYhLtU0vh80b+J >r5XClSUuQAzlWY6N6TOEHBWWDIxZ0Y2Jjx//Yz4x1XO6BVLs4Z0OhWsa0sZ+3cfg >e8jaTZHcTkX6rSZCXxExELJlsOke0KcA+IaPf/zQFJUiTEEteIck60GONKaPLtoC >mNaBAh7qJp7zzrl82OswiaJdksj+g76Xh4JdVFLlv1BDRbWiXVM= >=kSej >-END PGP SIGNATURE- > >- >To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >For additional commands, e-mail:
Re: Jakarta EE 9
On October 28, 2019 12:37:14 PM UTC, Johan Compagner wrote: >Hi > > > >On Mon, 28 Oct 2019 at 13:15, Mark Thomas wrote: > >> Hi all, >> >> A frequent topic of discussion at ApacheCon EU was Jakarta EE 9. For >those >> of you who aren't familiar with Jakarta EE the key points are: >> >> - Oracle have donated Java EE to Eclipse >> - Eclipse have released Jakarta EE 8 which is essentially identical >to >> Java EE 8 >> - Oracle have refused to allow changes to the APIs in the javax >namespace >> - The Jakarta EE community seem to be reaching consensus on releasing >> Jakarta EE 9 which will rename all the Java packages from javax.* to >> jakarta.* >> >> > >what does this rename really mean? > >import javax.servlet.http.HttpSession; >import javax.websocket.Session; > >those are renamed? >If that is yes that would mean pretty much everything will break? Correct. Hence the question on options for how we consider maintaining compatibility. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: JSP custom tag operating different when adoptOpenJDK is used vs Oracle (cross post from tomcat-taglibs-user)
That’s good to hear, you’re example works. In our tag class, which extends
org.apache.taglibs.standard.tag.common.fmt.FormatDateSupport, we have
setValue() overloaded, as follows…
public void setValue(final String value) {
public void setValue(final Object value) {
Is this a bad practice? How does tomcat decide which one to use. Why would
changing to adoptOpenJdk break this?
Thanks,
Jeff LoBello
Lead Software Engineer
Cerner | www.cerner.com>:
We have a custom tag, FormatDateTag extends
org.apache.taglibs.standard.tag.common.fmt.FormatDateSupport. It’s
been working ok for a number of years under tomcat & Oracle JVM. Now,
we are moving to adoptOpenJDK & we are seeing some differences in how
tomcat generation of JSP to Java classes happens when tomcat is doing
the EL evaluation. Here is an example JSP which shows the issue…
Which Java versions have you used exactly? What os was this? Which tomcat
version have you used?
Are there any other differences in the setup?
Felix
<%@ page language="java" contentType="text/html" isELIgnored="false" %>
<%@ page import="java.util.Date" %>
<%@ taglib uri="/WEB-INF/tld/suitags.tld" prefix="sui" %>
<%
Date chdt = new Date();
request.setAttribute("chdt", chdt);
%>
Looking at the compiled JSP source code under Oracle JVM, we see this…
// /tagUnitTests/sui/formatDate/testCaliHDateTime1.jsp(20,0) name =
value type = java.lang.Object reqTime = true required = true fragment =
false deferredValue = false expectedTypeName = null deferredMethod =
false methodSignature = null
_jspx_th_sui_005fformatDate_005f0.setValue((java.lang.Object)
org.apache.jasper.runtime.PageContextImpl.proprietaryEvaluate("${chdt}",
java.lang.Object.class,
(javax.servlet.jsp.PageContext)_jspx_page_context, null));
The same source compiled using AdoptOpenJDK, we see this…
// /tagUnitTests/sui/formatDate/ testCaliHDateTime1.jsp(20,0) name =
value type = java.lang.Object reqTime = true required = true fragment =
false deferredValue = false expectedTypeName = null deferredMethod
Re: Jakarta EE 9
On Mon, 28 Oct 2019 at 14:13, Rémy Maucherat wrote: > On Mon, Oct 28, 2019 at 1:46 PM Johan Compagner > wrote: > > > Hi > > > > > > > > On Mon, 28 Oct 2019 at 13:15, Mark Thomas wrote: > > > > > Hi all, > > > > > > A frequent topic of discussion at ApacheCon EU was Jakarta EE 9. For > > those > > > of you who aren't familiar with Jakarta EE the key points are: > > > > > > - Oracle have donated Java EE to Eclipse > > > - Eclipse have released Jakarta EE 8 which is essentially identical to > > > Java EE 8 > > > - Oracle have refused to allow changes to the APIs in the javax > namespace > > > - The Jakarta EE community seem to be reaching consensus on releasing > > > Jakarta EE 9 which will rename all the Java packages from javax.* to > > > jakarta.* > > > > > > > > > > what does this rename really mean? > > > > import javax.servlet.http.HttpSession; > > import javax.websocket.Session; > > > > those are renamed? > > If that is yes that would mean pretty much everything will break? > > > > https://eclipse-foundation.blog/2019/05/03/jakarta-ee-java-trademarks/ > I thought everyone knew about this. We were supposed to have a session on > this rename at ApacheCon EU, but unfortunately it didn't happen. > > Rémy > phh this is really horrible, one more reason to kind of hate Oracle.. this will split up a huge thing... So for example if you make Tomcat 10 to only have "jakarta.xxx" so all the existing code will not work on that anymore. then that tomcat will be for a long time in its own small corner.. We will not be able to use that for years to come.. because we have no control over what people are really using We still target java 8 (and that will also be the case for the coming years i am afraid) johan -- Johan Compagner Servoy
Re: Jakarta EE 9
On Mon, Oct 28, 2019 at 2:22 PM Michael Osipov wrote: > Am 2019-10-28 um 13:15 schrieb Mark Thomas: > > Hi all, > > > > A frequent topic of discussion at ApacheCon EU was Jakarta EE 9. For > those of you who aren't familiar with Jakarta EE the key points are: > > > > - Oracle have donated Java EE to Eclipse > > - Eclipse have released Jakarta EE 8 which is essentially identical to > Java EE 8 > > - Oracle have refused to allow changes to the APIs in the javax namespace > > - The Jakarta EE community seem to be reaching consensus on releasing > Jakarta EE 9 which will rename all the Java packages from javax.* to > jakarta.* > > - Jakarta EE 9 will not contain any other API changes > > - It will be a requirement to maintain backwards comparability (maybe > not 100% compatibility) with Jakarta EE 8 > > - Jakarta EE 9 will be released in the next ~11 months > > - Jakarta EE 10 will then follow which is where new features will be > introduced > > W/o going into the questions. You may want to answer two simple > questions to our users who solely use a servlet container like me: > > * Will my stuff break if I have written it against javax.servlet...? > * Since there is no canonical body (? is it Eclipse Foundation now) for > the specs, is there a possiblity that someone will fork the specs and > create their own, e.g., commercial vendors or Undertow, Netty, Jetty, > etc.?! (Mainly portability within the API) > Yes, the spec body for EE (starting with EE 9, which is functionally equivalent to EE 8 except for the package rename to jakarta.*) is now the Jakarta project at Eclipse. As with any standard, what matters is if people implement it. Rémy > > Michael > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Jakarta EE 9
Am 2019-10-28 um 13:15 schrieb Mark Thomas: Hi all, A frequent topic of discussion at ApacheCon EU was Jakarta EE 9. For those of you who aren't familiar with Jakarta EE the key points are: - Oracle have donated Java EE to Eclipse - Eclipse have released Jakarta EE 8 which is essentially identical to Java EE 8 - Oracle have refused to allow changes to the APIs in the javax namespace - The Jakarta EE community seem to be reaching consensus on releasing Jakarta EE 9 which will rename all the Java packages from javax.* to jakarta.* - Jakarta EE 9 will not contain any other API changes - It will be a requirement to maintain backwards comparability (maybe not 100% compatibility) with Jakarta EE 8 - Jakarta EE 9 will be released in the next ~11 months - Jakarta EE 10 will then follow which is where new features will be introduced W/o going into the questions. You may want to answer two simple questions to our users who solely use a servlet container like me: * Will my stuff break if I have written it against javax.servlet...? * Since there is no canonical body (? is it Eclipse Foundation now) for the specs, is there a possiblity that someone will fork the specs and create their own, e.g., commercial vendors or Undertow, Netty, Jetty, etc.?! (Mainly portability within the API) Michael - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Jakarta EE 9
On Mon, Oct 28, 2019 at 1:46 PM Johan Compagner wrote: > Hi > > > > On Mon, 28 Oct 2019 at 13:15, Mark Thomas wrote: > > > Hi all, > > > > A frequent topic of discussion at ApacheCon EU was Jakarta EE 9. For > those > > of you who aren't familiar with Jakarta EE the key points are: > > > > - Oracle have donated Java EE to Eclipse > > - Eclipse have released Jakarta EE 8 which is essentially identical to > > Java EE 8 > > - Oracle have refused to allow changes to the APIs in the javax namespace > > - The Jakarta EE community seem to be reaching consensus on releasing > > Jakarta EE 9 which will rename all the Java packages from javax.* to > > jakarta.* > > > > > > what does this rename really mean? > > import javax.servlet.http.HttpSession; > import javax.websocket.Session; > > those are renamed? > If that is yes that would mean pretty much everything will break? > https://eclipse-foundation.blog/2019/05/03/jakarta-ee-java-trademarks/ I thought everyone knew about this. We were supposed to have a session on this rename at ApacheCon EU, but unfortunately it didn't happen. Rémy
Re: Jakarta EE 9
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 10/28/19 08:15, Mark Thomas wrote: > Hi all, > > A frequent topic of discussion at ApacheCon EU was Jakarta EE 9. > For those of you who aren't familiar with Jakarta EE the key points > are: > > - Oracle have donated Java EE to Eclipse - Eclipse have released > Jakarta EE 8 which is essentially identical to Java EE 8 - Oracle > have refused to allow changes to the APIs in the javax namespace - > The Jakarta EE community seem to be reaching consensus on releasing > Jakarta EE 9 which will rename all the Java packages from javax.* > to jakarta.* - Jakarta EE 9 will not contain any other API changes > - It will be a requirement to maintain backwards comparability > (maybe not 100% compatibility) with Jakarta EE 8 - Jakarta EE 9 > will be released in the next ~11 months - Jakarta EE 10 will then > follow which is where new features will be introduced > > This raises various questions for the Tomcat community including: > > 1. Do we implement Jakarta EE 9? > > Assuming yes to q1. > > 2. As Tomcat 10 or some other version? > > 3. How do we manage development (in a branch, as master, ...)? > > 4. How do we implement backwards compatability? Runtime, deploy > time, compilation time? > > 5. At what point do we EOL Tomcat 7? (since Jakarta EE 9 is just a > package renaming?) > > 6. Do we commit to supporting Tomcat 9 for an extended period? (to > provide a version that supports java.* directly) > > I'm posting this to users@ as how Tomcat users want to use and > adopt Jakarta EE 9 is likely to be the biggest driving factor in > choosing answers to these questions. > > We don't have to have all of the answers right now. I think we do > need answers for 1 & 3 so we can start. A few options and 'wait and > see' is likely good enough for the rest for now. > > I have my own views on the answers but I have tried not to express > them here so we can get as wide a discussion as possible. How "simple" of a replacement are we talking about, here? For example, can it be done simply with sed? $ find . -type f | xargs sed -e 's/javax.servlet/jakarta.servlet/g' ? I'm asking because if it really is that easy, then we should be able to trivially package each of the existing Tomcat 7, 8.5, 9 releases as 7.jakarta, 8.5.jakarta, and 9.jakarta alongside their legacy Java EE versions. Users wanting to move to the Jakarta EE namespace can do so with existing, reliable versions of Tomcat instead of waiting for Tomcat 10 or Tomcat having to implement some kind of hybrid version which supports BOTH flavors of APIs (which seems kind of nightmarish to me). Are there any restrictions against us supporting Jakarta EE in existing Tomcat releases? I don't believe so. We merely advertise support for various standards; Tomcat is no longer the "reference implementation" of any APIs so we can do whatever we want, right? If we do a simply sed-style re-naming of packages to produce parallel releases, will they actually work? My sense is that, yes, they will indeed work. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl226RIACgkQHPApP6U8 pFjnfQ//bYExvm+BEhwroa/W+v3BGx+Bw0qtzz9MxjDIZ1zcGuxlITb1QdoYZ1sz C9eQumSo/gK1sO8ImVhMCYdFOf1n2az/olcMdF2v9gYC3YMZ11+qQhppYRxvfRvG pHzkV4PHbE6mgvfY9pli6LBs1Na1MSN0nRLluC4OBz3wMGCLQyByfBX3x+++8klB HHM1wcJDLzziIBmM3NKcuEFQ1gVbjlV10rFYes29KiuG4z78FRPY87pQmP+Xj71o l5NEtERYA+SjDGPZo6wrF6k3l23cZL/yrCp4PGwO1c0VB148DervvWG33+9OEOQL 1E8F0IZc2o2eiNYUxbUQcMxGXORnfbWpMyG8RVSVlwdhmzO4Ug1pxNVcpO2Y2qC2 vHHz+deQiQ/dZIsNU5aWtC+MBL7tx3RWxBNxb3n2d5T9tJm6zHBSdGfcPyTN14cV HTtPj9al4usxoT3XGSEhAP7FiI1RJXywq+o0sppaF6BrAh0UpRIYhLtU0vh80b+J r5XClSUuQAzlWY6N6TOEHBWWDIxZ0Y2Jjx//Yz4x1XO6BVLs4Z0OhWsa0sZ+3cfg e8jaTZHcTkX6rSZCXxExELJlsOke0KcA+IaPf/zQFJUiTEEteIck60GONKaPLtoC mNaBAh7qJp7zzrl82OswiaJdksj+g76Xh4JdVFLlv1BDRbWiXVM= =kSej -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: What's the purpose of this code, that logs a seemingly meaningless and possibly misleading exception?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Behrang,
On 10/26/19 20:22, Behrang Saeedzadeh wrote:
> Hi Chris,
>
> I suggested “massaging” it a bit before using the output:
>
> stack trace into a StringWriter via a PrintWriter, massage it a
> bit
>
> For example:
>
> StringWriter sw = new StringWriter(); PrintWriter pw = new
> PrintWriter(sw); Exception e = new Exception(); pw.append("Current
> stack trace:\n");for (StackTraceElement stackTraceElement :
> e.getStackTrace()) { pw.append("\tat
> ").append(stackTraceElement.toString()).append("\n"); }
>
> System.out.println(sw.toString());
>
> Which will produce:
>
> Current stack trace: at
> com.example.demo.DemoApplication.baz(DemoApplication.java:33) at
> com.example.demo.DemoApplication.foo(DemoApplication.java:20) at
> com.example.demo.DemoApplication.main(DemoApplication.java:15)
Other than writing to stdout, how is that any different from the
behavior of logger.debug("message", e) ? Are you just trying to get
rid of the "java.lang.Exception: message" part of the output?
I just don't understand how this is an improvement over what is
already there.
- -chris
> On Sun, Oct 27, 2019 at 7:48 AM Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
> Behrang,
>
> On 10/26/19 07:01, Behrang Saeedzadeh wrote:
I think so. Another option is to create an exception and
print the stack trace into a StringWriter via a PrintWriter,
massage it a bit if necessary and add that to the log
message.
>
> ... which would produce the same output?
>
> What's the goal of the change?
>
> -chris
>
On Sat, 26 Oct. 2019, 9:12 pm Mark Thomas,
wrote:
> On October 25, 2019 9:27:21 AM UTC, Behrang Saeedzadeh <
> behran...@gmail.com> wrote:
>> From Tomcat Embedded Core 9.0.26:
>>
>> @Override protected void doClose() { if
>> (log.isDebugEnabled()) { log.debug("Calling [" +
>> getEndpoint() + "].closeSocket([" + this + "])", new
>> Exception()); }
>>
>> Which will log something like:
>>
>> DEBUG [http-nio-8080-exec-2]
>> org.apache.tomcat.util.net.NioEndpoint Calling
>> [org.apache.tomcat.util.net.NioEndpoint@654c1a54
>
>> ].closeSocket([org.apache.tomcat.util.net.NioEndpoint$NioSocketWr
app
>
>>
er@39e9d240
>>
>>
> :org.apache.tomcat.util.net.NioChannel@78019ed5
> :java.nio.channels.SocketChannel[connected
>> local=/127.0.0.1:8080 remote=/127.0.0.1:39988]])
>>
>> java.lang.Exception: null at org.apache.tomcat.util.net
> .NioEndpoint$NioSocketWrapper.doClose(NioEndpoint.java:1165)
>>
>
[tomcat-embed-core-9.0.26.jar:9.0.26] at
>> org.apache.tomcat.util.net
> .SocketWrapperBase.close(SocketWrapperBase.java:394)
>> [tomcat-embed-core-9.0.26.jar:9.0.26] at
>> org.apache.tomcat.util.net
> .NioEndpoint$Poller.cancelledKey(NioEndpoint.java:667)
>> [tomcat-embed-core-9.0.26.jar:9.0.26] at
>> org.apache.tomcat.util.net
> .NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1592)
>> [tomcat-embed-core-9.0.26.jar:9.0.26] at
>> org.apache.tomcat.util.net
> .SocketProcessorBase.run(SocketProcessorBase.java:49)
>> [tomcat-embed-core-9.0.26.jar:9.0.26] at
>
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecu
tor
>
>>
.java:1149)
>>
>>
> [na:1.8.0_212]
>> at
>
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExec
uto
>
>>
r.java:624)
>>
>>
> [na:1.8.0_212]
>> at
>
>> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(Ta
skT
>
>>
hread.java:61)
>>
>>
> [tomcat-embed-core-9.0.26.jar:9.0.26]
>> at java.lang.Thread.run(Thread.java:748) [na:1.8.0_212]
>>
>> To print the stack trace next to the message?
>
> Yes. So the debug message shows what called close().
>
>> Every time I turn on debug logging this exception catches
>> me by surprise. Why not only print the stack trace next
>> using
>> org.apache.commons.lang3.exception.ExceptionUtils.getStackTrace
>>
>>
for example?
>
> Because that adds an entire library as a dependency to
> support a single debug message. And new Exception() gives
> what we need without that dependency. Would adding a
> message to the exception such as "Tracing caller" make
> things clearer?
>
> Mark
>
> --
- ---
>
>
>
>
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail:
> users-h...@tomcat.apache.org
>
>
>>
>> -
>>
>>
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
>
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird -
Re: Jakarta EE 9
Hi On Mon, 28 Oct 2019 at 13:15, Mark Thomas wrote: > Hi all, > > A frequent topic of discussion at ApacheCon EU was Jakarta EE 9. For those > of you who aren't familiar with Jakarta EE the key points are: > > - Oracle have donated Java EE to Eclipse > - Eclipse have released Jakarta EE 8 which is essentially identical to > Java EE 8 > - Oracle have refused to allow changes to the APIs in the javax namespace > - The Jakarta EE community seem to be reaching consensus on releasing > Jakarta EE 9 which will rename all the Java packages from javax.* to > jakarta.* > > what does this rename really mean? import javax.servlet.http.HttpSession; import javax.websocket.Session; those are renamed? If that is yes that would mean pretty much everything will break?
Jakarta EE 9
Hi all, A frequent topic of discussion at ApacheCon EU was Jakarta EE 9. For those of you who aren't familiar with Jakarta EE the key points are: - Oracle have donated Java EE to Eclipse - Eclipse have released Jakarta EE 8 which is essentially identical to Java EE 8 - Oracle have refused to allow changes to the APIs in the javax namespace - The Jakarta EE community seem to be reaching consensus on releasing Jakarta EE 9 which will rename all the Java packages from javax.* to jakarta.* - Jakarta EE 9 will not contain any other API changes - It will be a requirement to maintain backwards comparability (maybe not 100% compatibility) with Jakarta EE 8 - Jakarta EE 9 will be released in the next ~11 months - Jakarta EE 10 will then follow which is where new features will be introduced This raises various questions for the Tomcat community including: 1. Do we implement Jakarta EE 9? Assuming yes to q1. 2. As Tomcat 10 or some other version? 3. How do we manage development (in a branch, as master, ...)? 4. How do we implement backwards compatability? Runtime, deploy time, compilation time? 5. At what point do we EOL Tomcat 7? (since Jakarta EE 9 is just a package renaming?) 6. Do we commit to supporting Tomcat 9 for an extended period? (to provide a version that supports java.* directly) I'm posting this to users@ as how Tomcat users want to use and adopt Jakarta EE 9 is likely to be the biggest driving factor in choosing answers to these questions. We don't have to have all of the answers right now. I think we do need answers for 1 & 3 so we can start. A few options and 'wait and see' is likely good enough for the rest for now. I have my own views on the answers but I have tried not to express them here so we can get as wide a discussion as possible. Thoughts? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
