[GitHub] [tomcat-jakartaee-migration] ppkarwasz commented on pull request #16: Modifies TOMCAT profile
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 ``` 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: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] [tomcat-jakartaee-migration] ppkarwasz commented on pull request #16: Modifies TOMCAT profile
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: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] [tomcat-jakartaee-migration] ppkarwasz commented on pull request #16: Modifies TOMCAT profile
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: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] [tomcat-jakartaee-migration] ppkarwasz commented on pull request #16: Modifies TOMCAT profile
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: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] [tomcat-jakartaee-migration] ppkarwasz commented on pull request #16: Modifies TOMCAT profile
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 `` 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: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
