Re: Javax -> Jakarta rename
Hi everyone! I hope all is well with you all!! Jonathan, I see the project with few resources (Sorry for not helping much here!) and a lot sub-project to take care - do you understand? So, I would focus in, for example, build and certify tomEE on the Jakarta Web Profile (or minor one if the jakarta project create one) I known my vision is simplistic, but I think and see that the project would gain more engagement and resources with fewer sub-project(JSR and now JESP[1]), taking the direction of micronaut, spring-boot, dropwizard, etc. Regards, Gilberto [1] https://jakarta.ee/about/jesp/ On 2020/04/28 11:43:57, Jonathan Gallimore wrote: > Hi Gilberto > > Thanks for your post! I appreciate the you taking the time to post and give > your views. > > > I my opinion is the worst idea. TomEE has had a history of spread > projects and this way you will obligated to stay with all of them. > > Can you elaborate on what you mean with "this way you will [be] obligated > to stay with all of them"? > > > Reading about Jakarta EE 9 I've discovered that the goal is JDK11 -> > JAKARTA9 and of course the rename thing. > > That's not quite right. Java/JDK 8 is still the base for Jakarta EE 9. The > key difference between EE8 and EE9 is the package rename. You can use JDK > 11 with TomEE 8 today, and if you find something doesn't work, that is a > bug, and we'd want to fix it. We'll be targeting JDK 8 and 11 for Jakarta > EE 9. > > > But the main message is you do not need be backwards compatible (you can > if you wish). > > I'd call this out as the key part of your post. You're correct, > implementations do *not* need to be backwards compatible with Jakarta EE 8, > and they do not need to allow or be forgiving of any code that references > the old javax packages. The question we need to answer as a community is: > do we want to allow backwards compatibility? > > I'll very clearly state my own personal view is "yes", for the following > reasons: > > 1. One way or another, we will need to support EE 8 for a long time. TomEE > has a wide range of users, some will find the migration easy, and some will > take multiple years to migrate their applications. One option is to run > parallel branches for EE8 and EE9, but it is very unlikely that changes > will be mergeable across the two. We already have 3 active branches, and 4 > flavours of TomEE for each branch. Picking the one you want is already a > challenge. > > 2. One of the principals of TomEE is for the server to bend to fit the > user, not the other way around. Want to bring deployment descriptors from > another app server? No problem, we'll try and parse them and do the right > thing. I think breaking backwards compatibility would not be particularly > friendly to our consumers. > > 3. All of TomEE's competitors are likely to have backwards compatibility. > > I'd be interesting in hearing if others are in favour of dropping backwards > compatibility. > > I'm happy to look at other options to the Transformer, of course, but I > think it merits investigation, as it potentially gives us some quick wins. > > Jon > > > > On Tue, Apr 21, 2020 at 8:00 PM Gilberto Caetano de Andrade < > gilbert...@gmail.com> wrote: > > > Hi, > > > > On 2020/04/16 13:23:26, Jonathan Gallimore > > wrote: > > > Hi All, > > > > > > You may be aware that as part of the Jakarta EE 9 release later this > > year, > > > the various APIs provided in TomEE will be shifting from javax namespaces > > > to jakarta. > > > > > > I'm currently researching the use of the Eclipse Transformer project ( > > > https://projects.eclipse.org/projects/technology.transformer) to > > translate > > > both the TomEE server itself, and the source code for the examples. > > > > > > So far, I have a converted javaee-api.jar, and a Jakarta-ized version of > > > TomEE that boots. There's *lots* that doesn't work at the present moment, > > > but I'm expecting to have the moviefun example running fairly soon - that > > > covers EJB, Servlets, JSPs, JPA. The REST version of the sample also > > covers > > > JAX-RS too. > > > > > > I'm aware that there's also a migration tool that Tomcat have been > > working > > > on too, and will be looking at. > > > > > > We ought to have some discussion about the approach here - in my mind > > there > > > are some high-level goals: > > > > > > * Try and maintain a single codebase for javax and jakarta. > > I my opinion is the worst idea. TomEE has had a history of spread projects &
Re: Javax -> Jakarta rename
On 2020/04/21 19:00:54, Gilberto Caetano de Andrade wrote: > Hi, > > On 2020/04/16 13:23:26, Jonathan Gallimore > wrote: > > Hi All, > > > > You may be aware that as part of the Jakarta EE 9 release later this year, > > the various APIs provided in TomEE will be shifting from javax namespaces > > to jakarta. > > > > I'm currently researching the use of the Eclipse Transformer project ( > > https://projects.eclipse.org/projects/technology.transformer) to translate > > both the TomEE server itself, and the source code for the examples. > > > > So far, I have a converted javaee-api.jar, and a Jakarta-ized version of > > TomEE that boots. There's *lots* that doesn't work at the present moment, > > but I'm expecting to have the moviefun example running fairly soon - that > > covers EJB, Servlets, JSPs, JPA. The REST version of the sample also covers > > JAX-RS too. > > > > I'm aware that there's also a migration tool that Tomcat have been working > > on too, and will be looking at. > > > > We ought to have some discussion about the approach here - in my mind there > > are some high-level goals: > > > > * Try and maintain a single codebase for javax and jakarta. > I my opinion is the worst idea. TomEE has had a history of spread projects > and this way you will obligated to stay with all of them. > > >It's tempting to fork master and embark on a massive renaming exercise. > > I would like to suggest another way for the TomEE project with this great > opportunity (please consider my words, I'm not expert in lib, just user here > ok!) > Reading about Jakarta EE 9 I've discovered that the goal is JDK11 -> JAKARTA9 > and of course the rename thing. But the main message is you do not need be > backwards compatible (you can if you wish). > My suggestion is to follow the train like JDK11 -> JAKARTA9-> TomEE9 > The TomEE9 branch (I suggest it be the master one) will suffer the rename > task and prune the legacy project/dependency one > > Hardly I will upgrade or port my ee projects to jakata9 - I'm having a hard > time to update to jdk11 :) > I prefer stay with JDK8->TomEE8! > I mean I prefer stay with JDK8->JAKARTA8->TomEE8 for my current projects. For the new ones I prefer JDK11 -> JAKARTA9-> TomEE9. Sorry! > Regards, > Gilberto > > PS.: Thank you all for great project > > >That's complex as we'd need to do that for various dependencies as well, who > >may > > also have other branches and timelines. Having two codebases also means > > that any changes need to be applied twice, and with renamed packages, its > > unlikely the git merging or cherry-picking will work. > > > > * Be backwards compatible - One goal I had in my mined, is that if you have > > an application that uses javax, you'd probably like to be able to run it on > > a new Jakarta EE server. There are some options here - I quite like the > > idea of running the Transformer as a javaagent, so any applications > > deployed using the old namespaces are converted on the fly at the bytecode > > level. > > > > * Tooling - I wonder what tooling we could potentially provide? One thought > > I had was a Maven plugin that can transform a war/ear file for you as part > > of a build. > > > > Anyway, just wanted to give a heads-up on the research. Any thoughts / > > discussions / questions are encouraged. > > > > Jon > > >
Re: Javax -> Jakarta rename
Hi, On 2020/04/16 13:23:26, Jonathan Gallimore wrote: > Hi All, > > You may be aware that as part of the Jakarta EE 9 release later this year, > the various APIs provided in TomEE will be shifting from javax namespaces > to jakarta. > > I'm currently researching the use of the Eclipse Transformer project ( > https://projects.eclipse.org/projects/technology.transformer) to translate > both the TomEE server itself, and the source code for the examples. > > So far, I have a converted javaee-api.jar, and a Jakarta-ized version of > TomEE that boots. There's *lots* that doesn't work at the present moment, > but I'm expecting to have the moviefun example running fairly soon - that > covers EJB, Servlets, JSPs, JPA. The REST version of the sample also covers > JAX-RS too. > > I'm aware that there's also a migration tool that Tomcat have been working > on too, and will be looking at. > > We ought to have some discussion about the approach here - in my mind there > are some high-level goals: > > * Try and maintain a single codebase for javax and jakarta. I my opinion is the worst idea. TomEE has had a history of spread projects and this way you will obligated to stay with all of them. >It's tempting to fork master and embark on a massive renaming exercise. I would like to suggest another way for the TomEE project with this great opportunity (please consider my words, I'm not expert in lib, just user here ok!) Reading about Jakarta EE 9 I've discovered that the goal is JDK11 -> JAKARTA9 and of course the rename thing. But the main message is you do not need be backwards compatible (you can if you wish). My suggestion is to follow the train like JDK11 -> JAKARTA9-> TomEE9 The TomEE9 branch (I suggest it be the master one) will suffer the rename task and prune the legacy project/dependency one Hardly I will upgrade or port my ee projects to jakata9 - I'm having a hard time to update to jdk11 :) I prefer stay with JDK8->TomEE8! Regards, Gilberto PS.: Thank you all for great project >That's complex as we'd need to do that for various dependencies as well, who >may > also have other branches and timelines. Having two codebases also means > that any changes need to be applied twice, and with renamed packages, its > unlikely the git merging or cherry-picking will work. > > * Be backwards compatible - One goal I had in my mined, is that if you have > an application that uses javax, you'd probably like to be able to run it on > a new Jakarta EE server. There are some options here - I quite like the > idea of running the Transformer as a javaagent, so any applications > deployed using the old namespaces are converted on the fly at the bytecode > level. > > * Tooling - I wonder what tooling we could potentially provide? One thought > I had was a Maven plugin that can transform a war/ear file for you as part > of a build. > > Anyway, just wanted to give a heads-up on the research. Any thoughts / > discussions / questions are encouraged. > > Jon >
Re: Spring Boot Persistence Context
Maybe you need to adjust the config like this one [1] for weblogic.
Regards,
Gilberto
[1]
https://docs.spring.io/spring-boot/docs/current/rference/html/howto.html#howto-weblogic
On 2020/04/06 11:29:14, Jonathan Gallimore
wrote:
> Hi All,
>
> I'm looking at running a Spring Boot app in TomEE. Spring injects a
> persistence context into a bean managed by Spring:
>
> @EnableJpaRepositories(basePackages = "org.superbiz.movies.dao")
>
> @Repository
> public class MovieDao {
>
> @PersistenceContext(unitName = "movie-unit")
> private EntityManager entityManager;
>
> .
>
> }
>
> The .war created doesn't have a persistence.xml file, and so this fails
> validation. I've tried turning off CDI with a beans.xml file with
> bean-discovery-mode="none" - that doesn't make any difference.
>
> The exception is below. Does anyone have this working? I'm of the view that
> if the .war file works on Tomcat, it should also work with TomEE, without
> changes.
>
> I'll debug through to see if the @Repository class is a managed component,
> and if so, what sort of managed component it is and some options to try and
> get this usecase to work.
>
> 06-Apr-2020 12:19:11.435 INFO [main] org.hsqldb.persist.Logger.logInfoEvent
> Checkpoint end - txts: 1
> 06-Apr-2020 12:19:11.453 INFO [main]
> org.apache.openejb.config.AutoConfig.processResourceRef Auto-linking
> resource-ref 'jdbc/DefaultDB' in bean
> tomee-xa-tx-0.0.1-SNAPSHOT.Comp1802029863 to Resource(id=Default JDBC
> Database)
> 06-Apr-2020 12:19:11.496 INFO [main]
> org.apache.openejb.config.OutputGeneratedDescriptors.writeEjbJar Dumping
> Generated ejb-jar.xml to:
> /home/jgallimore/dev/tomee-xa-tx/target/apache-tomee/temp/ejb-jar-4834268279266350669tomee-xa-tx-0.0.1-SNAPSHOT.xml
> 06-Apr-2020 12:19:11.540 INFO [main]
> org.apache.openejb.config.OutputGeneratedDescriptors.writeOpenejbJar
> Dumping Generated openejb-jar.xml to:
> /home/jgallimore/dev/tomee-xa-tx/target/apache-tomee/temp/openejb-jar-1838234661417596634tomee-xa-tx-0.0.1-SNAPSHOT.xml
> 06-Apr-2020 12:19:11.565 SEVERE [main]
> org.apache.openejb.config.ReportValidationResults.logResults FAIL ...
> tomee-xa-tx-0.0.1-SNAPSHOT: Missing required persistence.xml for
> @PersistenceContext ref "entityManager" to unit "movie-unit"
> 06-Apr-2020 12:19:11.565 SEVERE [main]
> org.apache.openejb.config.ReportValidationResults.logResults Invalid
> EjbModule(name=tomee-xa-tx-0.0.1-SNAPSHOT,
> path=/home/jgallimore/dev/tomee-xa-tx/target/apache-tomee/webapps/tomee-xa-tx-0.0.1-SNAPSHOT)
> 06-Apr-2020 12:19:11.565 SEVERE [main]
> org.apache.openejb.config.ReportValidationResults.logResults FAIL ...
> tomee-xa-tx-0.0.1-SNAPSHOT: Missing required persistence.xml for
> @PersistenceContext ref "entityManager" to unit "movie-unit"
> 06-Apr-2020 12:19:11.566 SEVERE [main]
> org.apache.openejb.config.ReportValidationResults.logResults Invalid
> WebModule(name=tomee-xa-tx-0.0.1-SNAPSHOT,
> path=/home/jgallimore/dev/tomee-xa-tx/target/apache-tomee/webapps/tomee-xa-tx-0.0.1-SNAPSHOT)
> 06-Apr-2020 12:19:11.566 INFO [main]
> org.apache.openejb.config.ReportValidationResults.deploy Set the
> 'openejb.validation.output.level' system property to VERBOSE for increased
> validation details.
> 06-Apr-2020 12:19:11.566 SEVERE [main]
> org.apache.tomee.catalina.TomcatWebAppBuilder.startInternal Unable to
> deploy collapsed ear in war
> StandardEngine[Catalina].StandardHost[localhost].StandardContext[/tomee-xa-tx-0.0.1-SNAPSHOT]
> org.apache.openejb.config.ValidationFailedException: Module failed
> validation. AppModule(name=tomee-xa-tx-0.0.1-SNAPSHOT)
> at
> org.apache.openejb.config.ReportValidationResults.deploy(ReportValidationResults.java:88)
> at org.apache.openejb.config.AppInfoBuilder.build(AppInfoBuilder.java:327)
> at
> org.apache.openejb.config.ConfigurationFactory.configureApplication(ConfigurationFactory.java:1036)
> at
> org.apache.tomee.catalina.TomcatWebAppBuilder.startInternal(TomcatWebAppBuilder.java:1286)
> at
> org.apache.tomee.catalina.TomcatWebAppBuilder.configureStart(TomcatWebAppBuilder.java:1130)
> at
> org.apache.tomee.catalina.GlobalListenerSupport.lifecycleEvent(GlobalListenerSupport.java:134)
>
>
> 06-Apr-2020 12:19:11.435 INFO [main] org.hsqldb.persist.Logger.logInfoEvent
> Checkpoint end - txts: 1
> 06-Apr-2020 12:19:11.453 INFO [main]
> org.apache.openejb.config.AutoConfig.processResourceRef Auto-linking
> resource-ref 'jdbc/DefaultDB' in bean
> tomee-xa-tx-0.0.1-SNAPSHOT.Comp1802029863 to Resource(id=Default JDBC
> Database)
> 06-Apr-2020 12:19:11.496 INFO [main]
> org.apache.openejb.config.OutputGeneratedDescriptors.writeEjbJar Dumping
> Generated ejb-jar.xml to:
> /home/jgallimore/dev/tomee-xa-tx/target/apache-tomee/temp/ejb-jar-4834268279266350669tomee-xa-tx-0.0.1-SNAPSHOT.xml
> 06-Apr-2020 12:19:11.540 INFO [main]
> org.apache.openejb.config.OutputGeneratedDescriptors.writeOpenejbJar
> Dumping Generated openejb-jar.xml to:
>
Re: Subject for next blog post
forgot test code:
@PropertyFile("test-config.properties")
@RunWith(EJBContainerRunner.class)
public class ContratoParcelaServiceTest {
@Resource
private DataSource dataSource;
@EJB
private ContratoParcelaService parcelaService;
// the tracker is static because JUnit uses a separate Test instance for
every test method.
// used for read-only tests
private static final DbSetupTracker dbSetupTracker = new DbSetupTracker();
@Before
public void setUp() throws Exception {
Operation operation
= sequenceOf(
CommonOperations.DELETE_ALL,
CommonOperations.INSERT_REFERENCE_DATA);
// same DbSetup definition as above
DbSetup dbSetup = new DbSetup(new DataSourceDestination(dataSource),
operation);
// use the tracker to launch the DbSetup.
dbSetupTracker.launchIfNecessary(dbSetup);
}
@Test
public void parcelasComMesmoAdf() {
dbSetupTracker.skipNextLaunch();
List parcelas =
parcelaService.buscarParcelasPorAdf("000");
Assert.assertEquals(4, parcelas.size());
}
On 2020/01/03 15:22:41, gilbertoca wrote:
> I do use tomee-embedded-maven-plugin since 2015 (with help of Romain
> Manni-Bucau) like almost everyone did with
> tomcat-maven-plugin/jetty-maven-plugin.
> Ex.: mvn package tomee-embedded:run -P dev-postgresql -Dmaven.test.skip
>
> I setup a parametrized data-source in the web.xml and inject it everywhere
> (like the persistence.xml), switching between dev and prod databases.
> And make heavy use of openejb-junit package - specially the
> @RunWith(EJBContainerRunner.class) annotation.
>
>
>
> After that, I make a jar release with help the tomee-maven-plugin by
> running
> Ex.: mvn clean package tomee:exec -P prod -Dmaven.test.skip
>
> regards,
>
> Gilberto
>
> Happy new year!!
>
>
> Gabriel Ferreira wrote
> > I like Daniels proposal. +1 :D
> >
> > I have a curiosity how to embedded tomee in a project, to execute java
> > -jar
> > project.jar you know?
> >
> > May it's a subject too :)
> >
> >
> > On Thu, Dec 19, 2019, 5:48 PM Richard Monson-Haefel <
>
> > monsonhaefel@
>
> > >
> > wrote:
> >
> >> Good one, Daniel!
> >>
> >> On Thu, Dec 19, 2019 at 12:41 PM Daniel Dias Dos Santos <
> >>
>
> > daniel.dias.analistati@
>
> >> wrote:
> >>
> >> > Hello,
> >> >
> >> > maybe , configuring CDI in TomCat and DataSource .
> >> > --
> >> >
> >> > *Daniel Dias dos Santos*
> >> > Java Developer
> >> > SouJava & JCP Member
> >> > GitHub: https://github.com/Daniel-Dos
> >> > Linkedin: www.linkedin.com/in/danieldiasjava
> >> > Twitter: http://twitter.com/danieldiasjava
> >> >
> >> >
> >> > Em qui., 19 de dez. de 2019 às 09:41, Richard Monson-Haefel <
> >> >
>
> > monsonhaefel@
>
> >> escreveu:
> >> >
> >> > > what is a common mistake people make when configuring TomEE or
> >> Tomcat? I
> >> > > want that to be the topic of the blog post the week after next.
> >> > >
> >> > > Tomcat is sometimes better because it draws a larger audience. We
> >> can
> >> > talk
> >> > > about TomEE being Tomcat + at the start of the story raising
> >> awareness
> >> > and
> >> > > championing the project.
> >> > >
> >> > > --
> >> > > Richard Monson-Haefel
> >> > > https://twitter.com/rmonson
> >> > > https://www.linkedin.com/in/monsonhaefel/
> >> > >
> >> >
> >>
> >>
> >> --
> >> Richard Monson-Haefel
> >> https://twitter.com/rmonson
> >> https://www.linkedin.com/in/monsonhaefel/
> >>
>
>
>
>
>
> --
> Sent from: http://tomee-openejb.979440.n4.nabble.com/TomEE-Dev-f982480.html
>
