EjbCreate yönteminin EJB 3.0 sürümü nedir

Bazı eski EJB 2.1 kodlarını EJB 3.0'a taşımak istiyorum, ancak ejbCreate yönteminde bazı yapılandırma hataları ele alınıyor. Bu yöntemin EJB 3 sürümü var mı?

Düzenleme: EJB 2.x ejbCreate bir CreateException atabilir. @PostConstruct vb. Belgelerine dayanarak artık kontrol edilen İstisnaları atatamıyorum. Kodu EJB'yi kullanarak şimdi taşıyamazsam bunu nasıl halledebilirim.

Edit2: Ön uç, maalesef kontrol edilen CreateException'u özellikle ele alır.

 3
katma düzenlendi
Görünümler: 15
kaynak
ro ru fr es pt de zh hi bn ar kk

3 cevap

@PostConstruct
public void anyName() {
    //initialization code, dependencies are already injected
}

No only the name is arbitrary, you can have several @PostConstruct methods in one EJB - however the order of invocation is unspecified, so be careful and try to stick with one method. UPDATE:

Bu ek açıklama ile yalnızca bir yöntem eklenebilir.

6
katma
kaynak
"> " sınıfının kontrol altına alınmaması için kontrol edilmeyen bir istisna atar "- dokümanlar . İlk başta neden kontrol edilen istisnaları kullanmak istiyorsunuz? Ayrıca birkaç @PostConstruct yöntemini gerçekleştiremezsiniz , ilkbaharda çalışır, ancak EJB'de değil, üzgünüm.
katma yazar Tomasz Nurkiewicz, kaynak
EJB 3'te ejbCreate'e karşı% 100 işlevsel eşdeğer yoktur. Bizim durumumuzda, EJB'leri ön taraftaki refactor'yu yeniden düzenlemeye gerek kalmadan yeniden düzenleyemem anlamına gelir. Çözümü en azından problemimin bir kısmını çözdüğü için bu cevabı hala kabul edeceğim.
katma yazar Stefan, kaynak
Amaç, EJB ile ilgili bir sorun olduğunda müşteriyi bilgilendirmekti.
katma yazar Stefan, kaynak
Kontrol edilen istisnaları kullanmak istemiyorum. Ancak, EJB'yi kullanan kod, kontrol edilen 2.x özelliğine dayalı olarak CreateException işlemlerini gerçekleştirir. Ve şu anda bu kodu değiştiremiyorum.
katma yazar Stefan, kaynak
EJB 2.x'te ejbCreate bir CreateException atabilir. @PostConstruct belgelerine dayanarak artık kontrol edilen İstisnalar atayım. Kodu EJB'yi kullanarak şimdi taşıyamazsam bunu nasıl halledebilirim.
katma yazar Stefan, kaynak
EJB 2.x'in ejbCreate (-) 'in amacı neydi? EJB'nin yeni örneği oluşturulduğunda ve DI meydana geldiğinde, kapsayıcı tarafından @PostConstruct yöntemi çağrılır. Belki de yapılandırmanızı yapmak için @PostConstruct yöntemine ve ejbCreate (-) 'i simüle eden bazı modellere (normal yöntem) ihtiyacınız vardır.
katma yazar Piotr Nowicki, kaynak

Ek açıklamaları kullanarak EJB 3.0 yaşam döngüsü geri çağırma yöntemlerini kullanmanız gerekir

@PostConstruct, @PreDestroy, @PostActivate or @PrePassivate

Bu açıklamalar, herkese açık, geçersiz ve no-arg olan herhangi bir yönteme gidebilir.

2
katma
kaynak
Halka açık olması gerekmiyor. PostConstruct'ın javadoc'ından: "PostConstruct'ın uygulandığı yöntem, herkese açık, korunan, özel veya özel paket olabilir." docs.oracle.com/javaee/5/api/javax/ açıklama/& hellip;
katma yazar ymajoros, kaynak

Istemci açıkça ejbCreate tarafından atılan CreateException işlemek ve EJB 3 kullanmak istiyorsanız, o zaman durumlu bir oturum bean'i kullanıyor olmalısınız. Durum bilgisi olmayan oturum çekirdeklerinden gelen ejbCreate istemleri istemcilere yayılmaz ve varlık çekirdekleri EJB 3'teki ek açıklamaları desteklemez. Bu durumda, @ Init ek açıklaması istersiniz:

public interface MyHome extends EJBLocalHome {
  public MyInterface create(int arg) throws CreateException;
}

@Stateful
@LocalHome(MyHome.class)
public class MyBean {
  @Init
  public void init(int arg) throws CreateException {
    if (arg < 0) {
      throw new CreateException();
    }
  }
}
0
katma
kaynak
Haklısın; "WebSphere Application Server EJB kapsayıcı asla SLSB home.create kullanıcı tarafından görülebilir bir şekilde ejbCreate çağırır" :-) demeliydi. (Tek istisna ertelenmiş EJB ilklendirmesi sert bir minimum poolSize ile birleştirilmiştir, bu da fasulye havuzunun önceden doldurulmasına ve ejbCreate home.create sırasında ilk çağrılırken çağrılmasına neden olabilir.Ancak, bu durumda bile konteyner yakalayacaktır. CreateException ve arayan kişiye istisna yaymak yerine CNTR0033E sorun.)
katma yazar Brett Kail, kaynak
EJB kabı asla ejbCreate öğesini home.create'dan çağırmaz, ancak havuzu sizin belirttiğiniz şekilde doldururken çağırır. Bu nedenle, istemci kodunuz EJBException (veya RemoteException) alıyorsa ve getCause() öğesi CreateException olup olmadığını kontrol ediyorsa, istemci davranışının değiştirileceğini kabul ediyorum ve hedefinize ulaşmanın bir yolu yoktur. Müşteri kodun böyle mi yapıyor? Eğer öyleyse, özür dilerim ve tartışma için teşekkürler.
katma yazar Brett Kail, kaynak
Doğru, konteyner home.create'den ejbCreate çağrısı yapmıyor, bu yüzden "frontend, özellikle CreateException [ejbCreate from from]] komutunu geçersiz kılıyor. @PostConstruct'ı kullanabilir ve istediğiniz herhangi bir istisna atarsınız; müşteri davranışları değişmeyecektir.
katma yazar Brett Kail, kaynak
Anlamıyorum; Vatansız oturum çekirdeklerini daha önce nerede kullanıyorsunuz? Eğer öyleyse, o zaman müşterileriniz eJbCreate metodunuzdan atılan CreateException'ı asla görmeyecektir, çünkü bir vatansız oturum fasulyesi için home.create() ejbCreate'i çağırmaz. Bu nedenle, PostConstruct (ör. EJBException) herhangi bir özel durum kullanabilirsiniz ve istemci davranışı değişmez.
katma yazar Brett Kail, kaynak
"Ölçekleme ile" ne anlama geliyor?
katma yazar Brett Kail, kaynak
Ne yazık ki, ölçekleme ile ilgili bir sorun yaşıyorum.
katma yazar Stefan, kaynak
Durum bilgisi olan fasulye, çok sayıda kullanıcıyla çok iyi ölçeklenmez.
katma yazar Stefan, kaynak
Evet yaptı. Fasulye düzgün yüklenip yüklenmediğini kontrol eden ejbCreate kodumuz vardı. Eksik kavanozlar ve WAS6'daki DuplicateHomeExceptions ile ilgili bir sorun oluştu. Bu yüzden, statik başlatıcıda bulunan tüm sınıfları kontrol etmemiz gerekti ve daha sonra ejbCreate bunun sonucunu kontrol edecekti.
katma yazar Stefan, kaynak
Demek istediğin, bir fasulye yarattığın her zaman ejbCreate'i çağırmaz. Bu doğru. Hala havuzu doldurmak için çağırıyor ve buna ihtiyacım var.
katma yazar Stefan, kaynak
Hatalısınız. Konteyner ejbCreate'i çağırıyor. Sadece her çağrı oluşturmak için değil. Ancak, CreateException'ı ilk kez havuza doldurmaya çalıştığından beri, hiçbir zaman fasülyenin hiçbir örneği olmayacak ve evet, istemci bir CreateException alacak. theserverside.com/discussions/thread.tss?thread_id=6632 sayfasına bakın.
katma yazar Stefan, kaynak
Asla biraz kuvvetlidir, eminim ki Spec bunu yapmak için Container'a izin verir. Buna güvenemezsiniz, ancak createException öğesinin hala yayılmasının gerekli olduğu veya Kapsayıcının aslında ejbCreate işlevini çağırdığı anlamına gelmez. Ne yazık ki, birkaç yıl önce yaptığımız bazı tasarım kararları, EJB kavramı/standardı konusunda bir anlayış eksikliği olduğunu gösterdi. Şu anda geliştirmeye çalışıyoruz ama uygulamalarımızı kesintiye uğratmadan bunu yapmak zorundayız.
katma yazar Stefan, kaynak