You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by GitBox <gi...@apache.org> on 2021/03/23 16:38:48 UTC
[GitHub] [tomcat-jakartaee-migration] ppkarwasz opened a new pull request #16: Modifies TOMCAT profile
ppkarwasz opened a new pull request #16:
URL: https://github.com/apache/tomcat-jakartaee-migration/pull/16
Although Tomcat's code references several Jakarta EE APIs, it is distributed with just `annotations-api.jar`, `el-api.jar`, `jaspic-api.jar`, `servlet-api.jar` and `websocket-api.jar`. Therefore all the remaining APIs (e.g. Persistence API) are distributed with the applications.
The current TOMCAT profile causes most applications to fail with a `NoClassDefFoundError`, when the Migration Tool is used as `ClassTransformer` through the `<Loader jakartaConverter="TOMCAT" />` context configuration: the `WebAppClassloader` replaces many references to `javax.*` classes with `jakarta.*` classes, but does not make the inverse transformation, when loading the external API classes.
IMHO the migration tool shouldn't replace `javax.persistence` with `jakarta.persistence` also in other usage context, since this operation requires also the replacement of the JARs shipped with the application.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[GitHub] [tomcat-jakartaee-migration] martin-g commented on pull request #16: Modifies TOMCAT profile
Posted by GitBox <gi...@apache.org>.
martin-g commented on pull request #16:
URL: https://github.com/apache/tomcat-jakartaee-migration/pull/16#issuecomment-806695753
> 3\. The classloader fails to load the `jakarta.persistence.*` classes.
Fails how ? What is the exception ?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[GitHub] [tomcat-jakartaee-migration] ppkarwasz commented on pull request #16: Modifies TOMCAT profile
Posted by GitBox <gi...@apache.org>.
ppkarwasz commented on pull request #16:
URL: https://github.com/apache/tomcat-jakartaee-migration/pull/16#issuecomment-806549378
@rmaucher: I fail to understand how changing the `TOMCAT` profile will cause problems for others, because I don't understand the purpose of this profile. When one would want to use the `TOMCAT` profile instead of the `EE` profile?
The way I imagine it should work is:
1. You want to migrate your application to Jakarta EE 9, use the `EE` profile and **replace** all spec jars shipped with the application,
2. If you don't use any Java EE technology, besides those implemented by Tomcat, but you are using annotations: transform the application **before** deployment (IIRC the annotation scanner does not interact with the class loader),
3. If you are not using annotations nor `ServletContainerInitializer`s (the latter limitation can be relaxed), just configure the application context with `jakartaConverter="TOMCAT"` and deploy the application **as is**.
Of course I would settle for an alternative profile, which works for case 3.
Packaging both versions of the spec jars is also a solution, but our clients tend to upgrade our applications very rarely: some applications run a couple of years before they upgrade. We even found recently several Tomcat 8.0.5 and 9.0.0-M10 installations (probably they fought `M` stands for _max_). Therefore we are looking for a solution that requires the minimal amount of configuration to accommodate clients which run Tomcat 7.0 and Tomcat 10.0, possibly without modifying `CATALINA_HOME` (due to the widespread practice of _"upgrading"_ Tomcat by installing a new version and moving the `webapps` folder, all upgrades would require our intervention).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[GitHub] [tomcat-jakartaee-migration] ppkarwasz edited a comment on pull request #16: Modifies TOMCAT profile
Posted by GitBox <gi...@apache.org>.
ppkarwasz edited a comment on pull request #16:
URL: https://github.com/apache/tomcat-jakartaee-migration/pull/16#issuecomment-806549378
@rmaucher: I fail to understand how changing the `TOMCAT` profile will cause problems for others, because I don't understand the purpose of this profile. When one would want to use the `TOMCAT` profile instead of the `EE` profile?
The way I imagine it should work is:
1. You want to migrate your application to Jakarta EE 9, use the `EE` profile and **replace** all spec jars shipped with the application,
2. If you don't use any Java EE technology, besides those implemented by Tomcat, but you are using annotations: transform the application **before** deployment (IIRC the annotation scanner does not interact with the class loader) with the `TOMCAT` profile,
3. If you are not using annotations nor `ServletContainerInitializer`s (the latter limitation can be relaxed), just configure the application context with `jakartaConverter="TOMCAT"` and deploy the application **as is**.
Of course I would settle for an alternative profile, which works for case 3. I am bad with names, so a proposition is welcome.
Packaging both versions of the spec jars is also a solution, but our clients tend to upgrade our applications very rarely: some applications run a couple of years before they upgrade. We even found recently several Tomcat 8.0.5 and 9.0.0-M10 installations (probably they fought `M` stands for _max_). Therefore we are looking for a solution that requires the minimal amount of configuration to accommodate clients which run Tomcat 7.0 and Tomcat 10.0, possibly without modifying `CATALINA_HOME` (due to the widespread practice of _"upgrading"_ Tomcat by installing a new version and moving the `webapps` folder, all upgrades would require our intervention).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[GitHub] [tomcat-jakartaee-migration] rmaucher commented on pull request #16: Modifies TOMCAT profile
Posted by GitBox <gi...@apache.org>.
rmaucher commented on pull request #16:
URL: https://github.com/apache/tomcat-jakartaee-migration/pull/16#issuecomment-806448089
I perfectly understand [the problem is relocation of spec classes in the webapps], but there's no solution for you at the moment and I don't think this will be implemented. Did you actually try adding Jakarta API JARs to your webapp ? I don't see anything preventing you from doing this. Or you can put the API JARs in the Tomcat classloader too.
Your change in this PR will only suit your particular needs but will cause problems for others, so it cannot go in.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[GitHub] [tomcat-jakartaee-migration] rmaucher commented on pull request #16: Modifies TOMCAT profile
Posted by GitBox <gi...@apache.org>.
rmaucher commented on pull request #16:
URL: https://github.com/apache/tomcat-jakartaee-migration/pull/16#issuecomment-807107234
Since this is going nowhere, I'm trying something else to see if it could be a better solution to that problem when using the class transformer.
https://github.com/apache/tomcat-jakartaee-migration/commit/b89a835d5bca7e67e4ba0decf7e4e712c3b6aef5
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[GitHub] [tomcat-jakartaee-migration] martin-g commented on pull request #16: Modifies TOMCAT profile
Posted by GitBox <gi...@apache.org>.
martin-g commented on pull request #16:
URL: https://github.com/apache/tomcat-jakartaee-migration/pull/16#issuecomment-806465322
I still don't understand the setup.
Since both Tomcat and the app do not provide the extra API jars how this application works/worked on Tomcat 9.x ?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[GitHub] [tomcat-jakartaee-migration] ppkarwasz commented on pull request #16: Modifies TOMCAT profile
Posted by GitBox <gi...@apache.org>.
ppkarwasz commented on pull request #16:
URL: https://github.com/apache/tomcat-jakartaee-migration/pull/16#issuecomment-807166268
@martin-g: I am not running the migration tool and deploying the **jakartified** version. The migration tool works just fine in relocating the class files from `javax/*` to `jakarta/*` directory.
I am using a feature introduce by Rémy in [this commit](https://github.com/apache/tomcat/commit/abd1dead7804e99e3215e8e01a6cf7448a6b9f36) to deploy the **original** WAR file by simply setting the context to:
```lang-xml
<Context>
<Loader jakartaConverter="TOMCAT" />
</Context>
```
In this usage scenario the fact that the `TOMCAT` profile _jakartifies_ APIs that are not provided by Tomcat is a problem (beside the fact that the migration tool's `--help` states `TOMCAT (default) to convert Java EE APIs **provided** by Tomcat`). On the other hand the migration tool works fine even if I convert the same applications using the `EE`
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[GitHub] [tomcat-jakartaee-migration] ppkarwasz commented on pull request #16: Modifies TOMCAT profile
Posted by GitBox <gi...@apache.org>.
ppkarwasz commented on pull request #16:
URL: https://github.com/apache/tomcat-jakartaee-migration/pull/16#issuecomment-806715595
> > ```
> > 3\. The classloader fails to load the `jakarta.persistence.*` classes.
> > ```
>
> Fails how ? What is the exception ?
One of the standard `ClassNotFoundException` and `NoClassDefFoundError`. The reason is simple: the class that would be transformed into `jakarta.persistence.*` is still located in the `persistence-api.jar` as `javax/persistence/*.class`.
This of course doesn't happen for the 5 spec jars distributed with Tomcat: when the classloader loads a servlet that implements `javax.servlet.Servlet`, the transformer changes is to `jakarta.servlet.Servlet` and the interface is loaded correctly from `CATALINA_HOME/lib/servlet-api.jar` (unless of course somebody bundled a second version with the application, but this is his problem).
That's why I advocate to remove all APIs not bundled with Tomcat from the `TOMCAT` profile.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[GitHub] [tomcat-jakartaee-migration] martin-g commented on pull request #16: Modifies TOMCAT profile
Posted by GitBox <gi...@apache.org>.
martin-g commented on pull request #16:
URL: https://github.com/apache/tomcat-jakartaee-migration/pull/16#issuecomment-806722812
> is still located in the `persistence-api.jar` as `javax/persistence/*.class`.
This shouldn't be the case. The migrator should have updated it to jakarta/persistence/*.class.
Please provide a small application that demonstrates the problem.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[GitHub] [tomcat-jakartaee-migration] ppkarwasz edited a comment on pull request #16: Modifies TOMCAT profile
Posted by GitBox <gi...@apache.org>.
ppkarwasz edited a comment on pull request #16:
URL: https://github.com/apache/tomcat-jakartaee-migration/pull/16#issuecomment-806219210
Sorry, I didn't explain the context of this PR. I am testing the deployment of our Java EE 8 applications on Tomcat 10 using the `WebAppClassLoader` changes introduced in [this commit](https://github.com/apache/tomcat/commit/abd1dead7804e99e3215e8e01a6cf7448a6b9f36). We want to avoid having to distribute two versions of our applications for those clients, who for some reason do not want to deploy Tomcat 9.x. Since our applications don't rely on `ServletContainerInitializer`s it should be possible to convert them on-the-fly.
However a _"casual deploment"_ of our applications is impossible, since setting `<Loader jakartaConverter="TOMCAT" />` in Tomcat's configuration will rewrite also the API classes which are not provided by Tomcat (e.g. `javax.persistence` -> `jakarta.persitence`) and since our applications don't ship with jakartified versions of those APIs, this will result in a runtime error.
By `does not make the inverse transformation` I meant that the current Tomcat's classloader is unable to look for, e.g. `jakarta.persistence.EntityManager` in the `javax/persistence` directory (as a fallback) and jakartify it on the spot.
I admit that I don't see any practical difference between the `TOMCAT` profile and the full `EE` profile, since they both list a superset of specs implemented by Tomcat.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[GitHub] [tomcat-jakartaee-migration] ppkarwasz commented on pull request #16: Modifies TOMCAT profile
Posted by GitBox <gi...@apache.org>.
ppkarwasz commented on pull request #16:
URL: https://github.com/apache/tomcat-jakartaee-migration/pull/16#issuecomment-806658340
> I still don't understand the setup.
> Since both Tomcat and the app do not provide the extra API jars how this application works/worked on Tomcat 9.x ?
The app **provides** JPA 2.x API jars, but when I configure the application's classloader to transform using `jakartaConverter="TOMCAT"` the following happens:
1. The application loads a JPA entity class,
2. The `ClassFileTransformer` changes all `javax.persistence.*` annotations into `jakarta.persistence.*` annotations,
3. The classloader fails to load the `jakarta.persistence.*` classes.
I argue that `javax.persistence.*` and others (EJB, JAX-WS) should be removed from the `TOMCAT` profile. The only part of Tomcat's code, where there is a reference to JPA is the `InstanceManager`: whenever Tomcat instantiates a servlet class, it autowires the fields annotated with `@PersistenceContext`, etc. However this only works if there is a JPA implementation in Tomcat's _server_ classloader, i.e. we are deploying on TomEE (`EE` profile) or unusual Tomcat + JPA installation.
The remaining two APIs I removed from the `TOMCAT` profile (Java Mail and JTA) are, as far as I can see, only referenced in JNDI, so that applications can configure a mail `Session` or `UserTransaction` in their application context (if they ship with an implementation). For these applications I believe the `EE` profile is more appropriate.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[GitHub] [tomcat-jakartaee-migration] rmaucher closed pull request #16: Modifies TOMCAT profile
Posted by GitBox <gi...@apache.org>.
rmaucher closed pull request #16:
URL: https://github.com/apache/tomcat-jakartaee-migration/pull/16
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[GitHub] [tomcat-jakartaee-migration] ppkarwasz edited a comment on pull request #16: Modifies TOMCAT profile
Posted by GitBox <gi...@apache.org>.
ppkarwasz edited a comment on pull request #16:
URL: https://github.com/apache/tomcat-jakartaee-migration/pull/16#issuecomment-806219210
Sorry, I didn't explain the context of this PR. I am testing the deployment of our Java EE 8 applications on Tomcat 10 using the `WebAppClassLoader` changes introduced in [this commit](https://github.com/apache/tomcat/commit/abd1dead7804e99e3215e8e01a6cf7448a6b9f36). We want to avoid having to distribute two versions of our applications for those clients, who for some reason do not want to deploy Tomcat 9.x. Since our applications don't rely on `ServletContainerInitializer`s or Servlet 3.0 annotations it should be possible to convert them on-the-fly.
However a _"casual deploment"_ of our applications is impossible, since setting `<Loader jakartaConverter="TOMCAT" />` in Tomcat's configuration will rewrite also the API classes which are not provided by Tomcat (e.g. `javax.persistence` -> `jakarta.persitence`) and since our applications don't ship with jakartified versions of those APIs, this will result in a runtime error.
By `does not make the inverse transformation` I meant that the current Tomcat's classloader is unable to look for, e.g. `jakarta.persistence.EntityManager` in the `javax/persistence` directory (as a fallback) and jakartify it on the spot.
I admit that I don't see any practical difference between the `TOMCAT` profile and the full `EE` profile, since they both list a strict superset of specs implemented by Tomcat. As I mentioned before, Tomcat's code references some additional APIs, like EJB, JPA and JAX-WS, but only if those APIs are in the same classloader as the server classes (cf. [`DefaultInstanceManager`](https://github.com/apache/tomcat/blob/2fa851bf833acaa2774c7bfe0ee500ec03ece62d/java/org/apache/catalina/core/DefaultInstanceManager.java#L71): in those cases I would use the `EE` profile for migration.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[GitHub] [tomcat-jakartaee-migration] martin-g commented on pull request #16: Modifies TOMCAT profile
Posted by GitBox <gi...@apache.org>.
martin-g commented on pull request #16:
URL: https://github.com/apache/tomcat-jakartaee-migration/pull/16#issuecomment-805723404
The jars provided by Tomcat already use jakarta.** so they are not migrated. Only the classes coming from the application are migrated.
What do you mean with `WebAppClassloader replaces many references to javax.* classes with jakarta.* classes, but does not make the inverse transformation, when loading the external API classes.` ? What inverse transformation ?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[GitHub] [tomcat-jakartaee-migration] markt-asf commented on pull request #16: Modifies TOMCAT profile
Posted by GitBox <gi...@apache.org>.
markt-asf commented on pull request #16:
URL: https://github.com/apache/tomcat-jakartaee-migration/pull/16#issuecomment-806456674
Could we create another profile to address this?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[GitHub] [tomcat-jakartaee-migration] martin-g commented on pull request #16: Modifies TOMCAT profile
Posted by GitBox <gi...@apache.org>.
martin-g commented on pull request #16:
URL: https://github.com/apache/tomcat-jakartaee-migration/pull/16#issuecomment-805728912
I don't quite understand the description of the issue but looking at the code change it seems you want to use Servlet 5.x with EJB 3.x (i.e. Java EE 8 and earlier). Am I correct ?
I am not sure we want to support this combination. Your application should be either Java EE 8 or Jakarta EE 9, not a mix.
Even if your application comes with jakarta.** and javax.** classes then after migration all of them will be jakarta.**.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[GitHub] [tomcat-jakartaee-migration] martin-g commented on pull request #16: Modifies TOMCAT profile
Posted by GitBox <gi...@apache.org>.
martin-g commented on pull request #16:
URL: https://github.com/apache/tomcat-jakartaee-migration/pull/16#issuecomment-806727589
How do you deploy the app ?
Do you put yourApp.war in `webapps-javaee/` folder ?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[GitHub] [tomcat-jakartaee-migration] rmaucher commented on pull request #16: Modifies TOMCAT profile
Posted by GitBox <gi...@apache.org>.
rmaucher commented on pull request #16:
URL: https://github.com/apache/tomcat-jakartaee-migration/pull/16#issuecomment-805738456
I think he's describing what can be seen with the examples: EE spec API classes present in the webapp are not rewritten and relocated (in the examples: the JSTL API) and so are not "migrated". We're only going use of the said classes, not the classes themselves.
Summary: it is likely going to stay up to you to replace spec JARs that would be present in the application, as needed.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[GitHub] [tomcat-jakartaee-migration] ppkarwasz commented on pull request #16: Modifies TOMCAT profile
Posted by GitBox <gi...@apache.org>.
ppkarwasz commented on pull request #16:
URL: https://github.com/apache/tomcat-jakartaee-migration/pull/16#issuecomment-806219210
Sorry, I didn't explain the context of this PR. I am testing the deployment of our Java EE 8 applications on Tomcat 10 using the `WebAppClassLoader` changes introduced in [this commit](https://github.com/apache/tomcat/commit/abd1dead7804e99e3215e8e01a6cf7448a6b9f36). We want to avoid having to distribute two versions of our applications for those clients, who for some reason do not want to deploy Tomcat 9.x. Since our applications don't rely on `ServletContextInitializer`s it should be possible to convert them on-the-fly.
However a _"casual deploment"_ of our applications is impossible, since setting `<Loader jakartaConverter="TOMCAT" />` in Tomcat's configuration will rewrite also the API classes which are not provided by Tomcat (e.g. `javax.persistence` -> `jakarta.persitence`) and since our applications don't ship with jakartified versions of those APIs, this will result in a runtime error.
By `does not make the inverse transformation` I meant that the current Tomcat's classloader is unable to look for, e.g. `jakarta.persistence.EntityManager` in the `javax/persistence` directory (as a fallback) and jakartify it on the spot.
I admit that I don't see any practical difference between the `TOMCAT` profile and the full `EE` profile, since they both list a superset of specs implemented by Tomcat.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[GitHub] [tomcat-jakartaee-migration] rmaucher commented on pull request #16: Modifies TOMCAT profile
Posted by GitBox <gi...@apache.org>.
rmaucher commented on pull request #16:
URL: https://github.com/apache/tomcat-jakartaee-migration/pull/16#issuecomment-806478334
> I still don't understand the setup.
> Since both Tomcat and the app do not provide the extra API jars how this application works/worked on Tomcat 9.x ?
Going back to the JSTL spec and implementation in the examples webapp. The implementation classes get redirected to jakarta.servlet.jsp.jstl, however the classes are still looked up from the javax.servlet.jsp.jstl package. The spec classes from javax.* are not relocated to jakarta.*.
> Could we create another profile to address this?
Tomcat uses some classes that overlap the packages, so meh. JSTL is the best example, but there's also all the annotations.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[GitHub] [tomcat-jakartaee-migration] ppkarwasz edited a comment on pull request #16: Modifies TOMCAT profile
Posted by GitBox <gi...@apache.org>.
ppkarwasz edited a comment on pull request #16:
URL: https://github.com/apache/tomcat-jakartaee-migration/pull/16#issuecomment-806219210
Sorry, I didn't explain the context of this PR. I am testing the deployment of our Java EE 8 applications on Tomcat 10 using the `WebAppClassLoader` changes introduced in [this commit](https://github.com/apache/tomcat/commit/abd1dead7804e99e3215e8e01a6cf7448a6b9f36). We want to avoid having to distribute two versions of our applications for those clients, who for some reason do not want to deploy Tomcat 9.x. Since our applications don't rely on `ServletContainerInitializer`s or Servlet 3.0 annotations it should be possible to convert them on-the-fly.
However a _"casual deploment"_ of our applications is impossible, since setting `<Loader jakartaConverter="TOMCAT" />` in Tomcat's configuration will rewrite also the API classes which are not provided by Tomcat (e.g. `javax.persistence` -> `jakarta.persitence`) and since our applications don't ship with jakartified versions of those APIs, this will result in a runtime error.
By `does not make the inverse transformation` I meant that the current Tomcat's classloader is unable to look for, e.g. `jakarta.persistence.EntityManager` in the `javax/persistence` directory (as a fallback). Jakartifying on-the-fly references to the Annotation, EL, JASPIC, Servlet and Websocket classes works just fine (the classes can be found in Tomcat's classloader), but whenever a reference to another API is jakartified, the base class is not found.
I admit that I don't see any practical difference between the `TOMCAT` profile and the full `EE` profile, since they both list a strict superset of specs implemented by Tomcat. As I mentioned before, Tomcat's code references some additional APIs, like EJB, JPA and JAX-WS, but only if those APIs are in the same classloader as the server classes (cf. [`DefaultInstanceManager`](https://github.com/apache/tomcat/blob/2fa851bf833acaa2774c7bfe0ee500ec03ece62d/java/org/apache/catalina/core/DefaultInstanceManager.java#L71): in those cases I would use the `EE` profile for migration.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org