Datasource & Resource-Referenz

kleinevroni

Mitglied
Hallo,

ich hoffe das ist keine allzu doofe Anfänger Frage, aber ich hab jetzt einen Tag rumprobiert und komm auf keinen grünen Zweig :(

Also, ich benutze Glassfish v2.1 und EJB2.1 (noch ...)

Ich habe eine SessionBean mit den Deployment-Deskriptoren ejb-jar.xml und sun-ejb-jar.xml. Die Bean ist deployed, ich kann sie verwenden, alles passt.

ejb-jar:
Code:
<ejb-jar>
  <enterprise-beans>
    <session>
      <ejb-name>****</ejb-name>
      <home>com.....****Home</home>
      <remote>com.....***Remote</remote>
      <ejb-class>com......****</ejb-class>
      <session-type>Stateless</session-type>
      <transaction-type>Container</transaction-type>
     <resource-ref>
        <res-ref-name>jdbc/myDataSource</res-ref-name>
        <res-type>javax.sql.DataSource</res-type>
        <res-auth>Container</res-auth>
      </resource-ref>
    </session>
  </enterprise-beans>

</ejb-jar>

sun-ejb-jar
Code:
<sun-ejb-jar>
    <enterprise-beans>
		<ejb>
    <ejb-name>***</ejb-name>
    <jndi-name>***</jndi-name>   

      <resource-ref>
        <res-ref-name>jdbc/myDataSource</res-ref-name>
        <jndi-name>myPool</jndi-name>
      </resource-ref>   

    <pass-by-reference>false</pass-by-reference>
 </ejb>
 </enterprise-beans>
</sun-ejb-jar>


Dann gibts da noch eine Datenbank.
Im Glassfish ist der Connection Pool erzeugt & kann gepingt werden.
Die JDBC Resource heißt "myPool" und verweist auf den Pool.

Wenn ich von einer anderen EJB oder von irgendeinem Client aus einen lookUp auf myPool mache, kann ich mir eine Connection erzeugen und auf die DB zugreifen.

So weit so gut.

Jetzt will/muss ich aber nicht einen lookUp auf "myPool" machen, sondern auf "myDataSource". Ich dachte, dass der Glassfish mit den beiden xml-Dateien von der der jdbc/myDataSource zu myPool findet.
Aber so einfach ist das wohl nicht.

Folgendes hab ich probiert:
dataSource = (DataSource) ctx.lookup("myPool"); --> this works!
dataSource = (DataSource) ctx.lookup("myDataSource");
dataSource = (DataSource) ctx.lookup("jdbc/myDataSource");
dataSource = (DataSource) ctx.lookup("java:comp/env/jdbc/myDataSource");

Habt ihr eine Idee? Ich kann leider nicht mehr Infos bereitstellen, weil ich gar nicht weiß was relevant sein könnte :-(
 
Zuletzt bearbeitet:
Hallo,

also die beiden Deskriptoren sind ihmo soweit in Ordnung. Du solltest eigentlich in deiner SessionBean per
Code:
 dataSource = (DataSource) ctx.lookup("java:comp/env/jdbc/myDataSource");
auf die DataSource zugreifen können. Steht in den Server-Logs irgendwas brauchbares bzw. was kommt für eine Fehlermeldung.

Grüße
THMD
 
Hallo, danke für die schnelle Antwort.

Ich bekomme folgenden Fehler:

[#|2009-09-07T14:30:52.199+0200|WARNING|sun-appserver2.1|javax.enterprise.system.stream.err|_ThreadID=15;_ThreadName=p: thread-pool-1; w: 5;_RequestID=6f97abf4-6160-41fc-a9ea-4ac6bc07e119;|
javax.naming.NameNotFoundException: myDataSource not found
at com.sun.enterprise.naming.TransientContext.doLookup(TransientContext.java:216)
at com.sun.enterprise.naming.TransientContext.lookup(TransientContext.java:188)
at com.sun.enterprise.naming.SerialContextProviderImpl.lookup(SerialContextProviderImpl.java:74)
at com.sun.enterprise.naming.LocalSerialContextProviderImpl.lookup(LocalSerialContextProviderImpl.java:111)
at com.sun.enterprise.naming.SerialContext.lookup(SerialContext.java:409)
at javax.naming.InitialContext.lookup(InitialContext.java:351)
at com.bmw.fkdm.customer.CustomerManager.getDataSource(CustomerManager.java:95)
at com.bmw.fkdm.customer.CustomerManager.isFKDMCustomer(CustomerManager.java:164)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at com.sun.enterprise.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1011)
at com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:175)
at com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:2920)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:4011)
at com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:203)
at com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:120)

und zwar mit allen diesen Varianten:
dataSource = (DataSource) ctx.lookup("myDataSource");
dataSource = (DataSource) ctx.lookup("jdbc/myDataSource");
dataSource = (DataSource) ctx.lookup("java:comp/env/jdbc/myDataSource");
 
Hallo nochmal,

das Problem hab ich heraus gefunden:

Mein Ant-Task, der die jars mit den einzelnen EJBs erstellt packt das sun-ejb-jar.xml nicht mit rein.
Deswegen generiert der Glassfish dann selber eins, wo natürlich nicht myPool drinsteht sondern wieder "myDatasource".

Wenn ich per Hand ein jar mit dem sun...xml erstelle und dann den lookup mache mit comp:env etc. funktioniert es.

Soweit so gut.

Daraus ergibt sich nun folgende Frage - gibt es einen Ant Task für Sun bzw. Glassfish der mir automatisch das richtige baut? Für Weblogic zB gibt es in "ejbjar" den subtask "weblogic", der automatisch das den weblogic-spezifischen Deskriptor mit packt.

Für Sun gibt es leider keinen solchen. ejbjar jar ist halt ganz praktisch, weil es sich selber sucht, welche EJBs vorhanden sind und dann einzelne Jars erstellt.

Hat jmd da Erfahrung? Mit nem einzelnen würde ich einfach <jar>... etc. machen.

Aber ich hab einige EJBs und für die alle nen Task schreiben, das will ich mir eigtl nicht antun.
 
Hallo,

danke.

Leider such ich nicht den Task zum Generieren der sun-ejb-jar-xml (Die hab ich schon.)

Sondern ich suche etwas, das mir automatisch (anhand der vorhandenen Deployment-Deskriptoren) viele kleine Jar-Dateien erstellt. Das macht ja eigtl. der <ejbjar> Task . mit dem kleinen aber feinen Fehler, dass die eine Datei fehlt.

Als ich noch auf weblogic war konnte ich den subtask für weblogic verwenden. Für Sun gibt es aber keinen.

Daher die Frage ob man das irgendwie austricksen kann, oder ob es einen ganz anderen Weg gibt.
 
Hallo,

sorry, hatte geistig nur das mit dem spezifischen Deploymentdeskriptor erfasst ;)
Für den <ejbjar> hast Du natürlich recht, da gibt es sowas für Sun nicht (bzw. ich kenne keinen)

Aber im allgemeinen versteh ich nicht ganz, warum du für jede EJB ein eigenes jar-Archive erstellen möchtest. Ist dein Einsatzszenario so komplex, dass du die Dinger alle extra deployen musst? Falls nicht, pack sie alle in ein jar -Archive. Dann brauchst du auch den Deskriptor nur einmal.

Grüße
THMD
 
:D
Passiert mir auch permanent.

Naja, das ist halt, wie man so schön sagt "historisch gewachsen" (und hat 50'000 Zeilen Code, also simpel is es nicht) - hat halt mein Vorgänger so gemacht.
Und bevor ich mich an die Arbeit mache da was zu ändern wollte ich schauen obs nicht anders geht :eek:

Aber da werde ich wohl in den sauren Apfel beißen müssen.
 

Neue Beiträge

Zurück