Sta mislite, kakve su sanse da se u buducnosti JPA razvije kao posebna tehnologija, nezavisna od EJB tehnologije, kako bi se entiteti bazirani na JPA mogli korisiti i u drugim vrstama aplikacija (pored EJB aplikacija)?
JPA kao posebna tehnologija?
Zaključano
Zakačeno
Pa, to je i sada moguce.
Treba samo da ubacis nekoliko jar fajlova u biblioteku, i mozes da koristis JPA u standalone aplikacijama.
Po meni je JPA odlicna tehnologija, i nema potrebe direktno raditi sa bilo kojim drugim ORM framework-om. A u pozadini ce ionako raditi Hibernate ili TopLink.
Treba samo da ubacis nekoliko jar fajlova u biblioteku, i mozes da koristis JPA u standalone aplikacijama.
Po meni je JPA odlicna tehnologija, i nema potrebe direktno raditi sa bilo kojim drugim ORM framework-om. A u pozadini ce ionako raditi Hibernate ili TopLink.
izmenjeno 1 put, poslednji put Vanja Petreski 17.11.2006. u 15:25
Izmene poruke
- Vanja Petreski17.11.2006. u 15:25zapis iz teksta poruke
Nemoj da zezas, nisam imao pojma da to moze? :)
Fenomenalno!
Ja sam skapirao da je EJB 3.0 specifikacija razvijena pod JSR 220 i da je podeljena u 3 dela, a da je jedan od njih upravo JPA, pa sam zato zakljucio da se moze koristiti iskljucivo u EJB aplikaciji...
Pozdrav
Fenomenalno!
Ja sam skapirao da je EJB 3.0 specifikacija razvijena pod JSR 220 i da je podeljena u 3 dela, a da je jedan od njih upravo JPA, pa sam zato zakljucio da se moze koristiti iskljucivo u EJB aplikaciji...
Pozdrav
Aha, evo ga:
Q: What are the advantages of the Java Persistence API?
A: The Java Persistence API draws upon the best ideas from persistence technologies such as Hibernate, TopLink, and JDO. Customers now no longer face the choice between incompatible non-standard persistence models for object/relational mapping. In addition, the Java Persistence API is usable both within Java SE environments as well as within Java EE, allowing many more developers to take advantage of a standard persistence API.
Q: Why was the Java Persistence API developed as part of JSR-220 (EJB 3.0)?
A: The Java Persistence API originated as part of the work of the JSR 220 Expert Group to simplify EJB CMP entity beans. It soon became clear to the expert group, however, that a simplification of EJB CMP was not enough, and that what was needed was a POJO persistence framework in line with other O/R mapping technologies available in the industry. Once an Earlier Draft of the EJB 3.0 specification including the Java Persistence API was released, the JSR-220 Expert Group received many requests from the community that this work be made available beyond just the scope of EJB.
Q: Why didn't you split off the Java Persistence API work into a separate JSR?
A: We believed that leveraging the work in the context of JSR-220 would minimize risk and deliver a high quality result more quickly. Further, it was important that this API integrate smoothly and consistently with the rest of the simplifications to the EJB 3.0 APIs. It therefore seemed best to extend this ongoing project, and draw additional experts into the JSR-220 group as appropriate as the work expanded.
Q: What if I want to use the Java Persistence API outside of the Java EE platform?
A: The specification, RI, and TCK insure that the Java Persistence API works with Java SE as well as with Java EE. Passing the TCK for the Java SE portion allows vendors to be compliant with the Java Persistence API without having a Java EE certification.
I evo ga:
Q: How will the Java Persistence API evolve now that JSR 220 has been completed?
A: We expect to spin off the Java Persistence API into its own new JSR for future evolution. This means subsequent versions of the Java Persistence API will not be tied to future EJB JSRs. We expect to continue to draw expertise from a diversity of sources, quite likely including many of the members of the JSR 220 Expert Group who helped define the Java Persistence API.
[quote]
Q: Will the Java Persistence API become part of Java SE?
A: There are no current plans to include the Java Persistence API in Java SE. As the Java Persistence API evolves, however, it is likely that this issue will be considered by the Java SE expert group in a future Java SE release.
[quote]
Citat:
Q: What are the advantages of the Java Persistence API?
A: The Java Persistence API draws upon the best ideas from persistence technologies such as Hibernate, TopLink, and JDO. Customers now no longer face the choice between incompatible non-standard persistence models for object/relational mapping. In addition, the Java Persistence API is usable both within Java SE environments as well as within Java EE, allowing many more developers to take advantage of a standard persistence API.
Citat:
Q: Why was the Java Persistence API developed as part of JSR-220 (EJB 3.0)?
A: The Java Persistence API originated as part of the work of the JSR 220 Expert Group to simplify EJB CMP entity beans. It soon became clear to the expert group, however, that a simplification of EJB CMP was not enough, and that what was needed was a POJO persistence framework in line with other O/R mapping technologies available in the industry. Once an Earlier Draft of the EJB 3.0 specification including the Java Persistence API was released, the JSR-220 Expert Group received many requests from the community that this work be made available beyond just the scope of EJB.
Citat:
Q: Why didn't you split off the Java Persistence API work into a separate JSR?
A: We believed that leveraging the work in the context of JSR-220 would minimize risk and deliver a high quality result more quickly. Further, it was important that this API integrate smoothly and consistently with the rest of the simplifications to the EJB 3.0 APIs. It therefore seemed best to extend this ongoing project, and draw additional experts into the JSR-220 group as appropriate as the work expanded.
Citat:
Q: What if I want to use the Java Persistence API outside of the Java EE platform?
A: The specification, RI, and TCK insure that the Java Persistence API works with Java SE as well as with Java EE. Passing the TCK for the Java SE portion allows vendors to be compliant with the Java Persistence API without having a Java EE certification.
I evo ga:
Citat:
Q: How will the Java Persistence API evolve now that JSR 220 has been completed?
A: We expect to spin off the Java Persistence API into its own new JSR for future evolution. This means subsequent versions of the Java Persistence API will not be tied to future EJB JSRs. We expect to continue to draw expertise from a diversity of sources, quite likely including many of the members of the JSR 220 Expert Group who helped define the Java Persistence API.
[quote]
Q: Will the Java Persistence API become part of Java SE?
A: There are no current plans to include the Java Persistence API in Java SE. As the Java Persistence API evolves, however, it is likely that this issue will be considered by the Java SE expert group in a future Java SE release.
[quote]
izmenjeno 1 put, poslednji put Black 23.11.2006. u 03:39
Izmene poruke
- Black23.11.2006. u 03:39zapis iz teksta poruke
Evo primera, kako je jednostavno koristiti Java Persistence u Java SE okruzenju.
Treba samo ukljuciti biblioteke toplink-essentials.jar i derbyclient.jar u program.
Treba samo ukljuciti biblioteke toplink-essentials.jar i derbyclient.jar u program.
Code:
Using in Java SE
First, we need to create an EntityManagerFactory that we will use in the example.
An EntityManagerFactory is created once for each PersistentUnit.
Persistent unit in this example is called "pu1".
// Create EntityManagerFactory for persistent unit named "pu1"
// to be used in this test
emf = Persistence.createEntityManagerFactory("pu1");
For each business method in the example, a new EntityManager is created:
// Create new EntityManager
em = emf.createEntityManager();
If a transaction required, it is started:
// Begin transaction
em.getTransaction().begin();
And then the business logic is executed in a separate business method:
// Business logic
mybusinessmethod(...);
If transaction has been started it must be committed:
// Commit the transaction
em.getTransaction().commit();
And EntityManager should always be closed if it won't be used again:
// Close this EntityManager
em.close();
Using in Java SE
First, we need to create an EntityManagerFactory that we will use in the example.
An EntityManagerFactory is created once for each PersistentUnit.
Persistent unit in this example is called "pu1".
// Create EntityManagerFactory for persistent unit named "pu1"
// to be used in this test
emf = Persistence.createEntityManagerFactory("pu1");
For each business method in the example, a new EntityManager is created:
// Create new EntityManager
em = emf.createEntityManager();
If a transaction required, it is started:
// Begin transaction
em.getTransaction().begin();
And then the business logic is executed in a separate business method:
// Business logic
mybusinessmethod(...);
If transaction has been started it must be committed:
// Commit the transaction
em.getTransaction().commit();
And EntityManager should always be closed if it won't be used again:
// Close this EntityManager
em.close();
Ovde ocigledno nema middleware servisa kontejnera ;)
Btw, sta ce ti Derby?
Citat:
Vanja Petreski: Btw, sta ce ti Derby?
Pa, koristio sam Derby bazu za neki projekat, pa mi je to prvo palo na pamet, ali naravo da ce posluziti i bilo koja druga BP :)