La recherche JNDI pour la JTA UserTransaction est pas disponible pour les discussions MBean dans Websphere Application Server 7

StackOverflow https://stackoverflow.com/questions/8343533

  •  27-10-2019
  •  | 
  •  

Question

Je suis en train d'invoquer la logique métier via JMX (en utilisant « standard » MBeans) dans une application Web dans Websphere Application Server 7 avec JTA allumé et je voudrais savoir pourquoi cette logique d'entreprise ne peut pas voir le JTA UserTransaction quand invoqué à partir d'un MBean (car il peut lorsqu'elle est invoquée par l'interface utilisateur de l'application Web).

lorsqu'Hibernate tente de regarder le UserTransaction via 'java: comp / UserTransaction', l'exception suivante est levée: 

org.hibernate.TransactionException: Could not find UserTransaction in JNDI [java:comp/UserTransaction]
    at org.hibernate.transaction.JTATransactionFactory.getUserTransaction(JTATransactionFactory.java:173)
    at org.hibernate.transaction.JTATransactionFactory.createTransaction(JTATransactionFactory.java:149)

    ...

    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
    at java.lang.reflect.Method.invoke(Method.java:600)
    at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:105)
    at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:39)
    at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:220)
    at com.sun.jmx.mbeanserver.PerInterface.getAttribute(PerInterface.java:77)
    at com.sun.jmx.mbeanserver.MBeanSupport.getAttribute(MBeanSupport.java:228)
    at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:678)
    at com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:650)
    at com.ibm.ws.management.AdminServiceImpl.getAttribute(AdminServiceImpl.java:853)
    at com.ibm.ws.management.remote.AdminServiceForwarder.getAttribute(AdminServiceForwarder.java:270)
    at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1415)
    at javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:84)
    at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1276)
    at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1371)
    at javax.management.remote.rmi.RMIConnectionImpl.getAttribute(RMIConnectionImpl.java:612)
    at javax.management.remote.rmi._RMIConnectionImpl_Tie.getAttribute(_RMIConnectionImpl_Tie.java:578)
    at javax.management.remote.rmi._RMIConnectionImpl_Tie._invoke(_RMIConnectionImpl_Tie.java:98)
    at com.ibm.CORBA.iiop.ServerDelegate.dispatchInvokeHandler(ServerDelegate.java:622)
    at com.ibm.CORBA.iiop.ServerDelegate.dispatch(ServerDelegate.java:475)
    at com.ibm.rmi.iiop.ORB.process(ORB.java:513)
    at com.ibm.CORBA.iiop.ORB.process(ORB.java:1574)
    at com.ibm.rmi.iiop.Connection.respondTo(Connection.java:2841)
    at com.ibm.rmi.iiop.Connection.doWork(Connection.java:2714)
    at com.ibm.rmi.iiop.WorkUnitImpl.doWork(WorkUnitImpl.java:63)
    at com.ibm.ejs.oa.pool.PooledThread.run(ThreadPool.java:118)
    at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1563)
Caused by: javax.naming.ConfigurationException: A JNDI operation on a "java:" name cannot be completed because the server runtime is not able to associate the operation's thread with any J2EE application component.  This condition can occur when the JNDI client using the "java:" name is not executed on the thread of a server application request.  Make sure that a J2EE application does not execute JNDI operations on "java:" names within static code blocks or in threads created by that J2EE application.  Such code does not necessarily run on the thread of a server application request and therefore is not supported by JNDI operations on "java:" names. [Root exception is javax.naming.NameNotFoundException: Name "comp/UserTransaction" not found in context "java:".]
    at com.ibm.ws.naming.java.javaURLContextImpl.throwConfigurationExceptionWithDefaultJavaNS(javaURLContextImpl.java:428)
    at com.ibm.ws.naming.java.javaURLContextImpl.lookup(javaURLContextImpl.java:399)
    at com.ibm.ws.naming.java.javaURLContextRoot.lookup(javaURLContextRoot.java:214)
    at com.ibm.ws.naming.java.javaURLContextRoot.lookup(javaURLContextRoot.java:154)
    at javax.naming.InitialContext.lookup(InitialContext.java:455)
    at org.hibernate.transaction.JTATransactionFactory.getUserTransaction(JTATransactionFactory.java:163)
    ... 53 more
Caused by: javax.naming.NameNotFoundException: Name "comp/UserTransaction" not found in context "java:".
    at com.ibm.ws.naming.ipbase.NameSpace.lookupInternal(NameSpace.java:1178)
    at com.ibm.ws.naming.ipbase.NameSpace.lookup(NameSpace.java:1095)
    at com.ibm.ws.naming.urlbase.UrlContextImpl.lookup(UrlContextImpl.java:1233)
    at com.ibm.ws.naming.java.javaURLContextImpl.lookup(javaURLContextImpl.java:395)
    ... 57 more

Cette apparence de problème comme il est plus qu'un simple problème de configuration de mise en veille prolongée - Mise en veille prolongée est à la recherche de UserTransaction à ce que disent IBM est l'emplacement JNDI UserTransaction correct ( 'java: comp / UserTransaction') - voir ce document de infocentre .

En outre, je peux reproduire le problème dans un simple application web qui a un MBean qui fait la recherche: 

public class JTALookup extends NotificationBroadcasterSupport implements JTALookupMBean {
  Log log = LogFactory.getLog(JTALookup.class);

  /**
   * {@inheritDoc}
   * @see JTALookupMBean#lookupUserTransaction()
   */
  @Override
  public void lookupUserTransaction() {
    try {
      log.info("Attempting 'java:comp/UserTransaction' lookup");
      Object usrTxn = new InitialContext().lookup("java:comp/UserTransaction");
      log.info("Successfully looked up 'java:comp/UserTransaction' [" + usrTxn + "]." );
    } catch (NamingException e) {
      log.info("'java:comp/UserTransaction' lookup failed");
      throw new RuntimeException("Failed to lookup JTA user transaction", e);
    }
  }

et un auditeur de contexte qui fait intervenir la recherche lors du démarrage puis enregistre le MBean: 

public void contextInitialized(ServletContextEvent sce) {

    log.info("Initialising context");

    JTALookup jtaLookup = new JTALookup();
    jtaLookup.lookupUserTransaction(); // This succeeds
    log.info("Looked up JTA transaction");

    MBeanServer mbServer = AdminServiceFactory.getMBeanFactory().getMBeanServer();
    log.info("Got MBeanServer");

    try {
      mbServer.registerMBean(jtaLookup, new ObjectName("webJTALookupStub:type=JTALookup"));
      log.info("Registered dummy MBean");
    } catch (Exception e) {
      log.info("Failed to register dummy MBean");
      throw new RuntimeException("Failed to register dummy MBean", e);
    }
}

La recherche sur « java: comp / UserTransaction » succède au cours de l'initialisation du contexte, mais échoue (avec une trace de pile semblable à celle ci-dessus) lorsqu'il est appelé par l'intermédiaire d'jmx, comme suit: 

public static void main(String[] args) {

    JMXServiceURL url = new JMXServiceURL(
        "service:jmx:rmi://" + "your.server.name.co.uk" + ":" + "2809" + "/jndi/JMXConnector"
    );

    Hashtable<String, Object> env = new Hashtable<String, Object>();
    env.put(Context.PROVIDER_URL, "corbaloc:iiop:gbbldd66.sys.chp.co.uk:2809/WsnAdminNameService");
    env.put(Context.INITIAL_CONTEXT_FACTORY, "com.ibm.websphere.naming.WsnInitialContextFactory");

    // Establish the JMX connection.
    JMXConnector jmxc = JMXConnectorFactory.connect(url, env);

    // Get the MBean server connection instance.
    MBeanServerConnection mbsc = jmxc.getMBeanServerConnection();

    ObjectName mbeanName = new ObjectName("webJTALookupStub:type=JTALookup");

    JTALookupMBean mBean = JMX.newMBeanProxy(mbsc, mbeanName, JTALookupMBean.class, true);

    mBean.lookupUserTransaction(); // This fails

" l'extension du système d'administration de WebSphere application Server avec MBeans personnalisés de documents dans InfoCenter d'IBM suggère que MBeans standards qui ont été testés dans des applications en dehors WAS devrait fonctionner.

IBM font état que la recherche UserTransaction n'est pas disponible à:

  • CMT entreprise haricots `http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.base.doc/info/aes/ae /cjta_glotran.html

  • Async Beans créés par `http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.javadoc.doc/web/apidocs/com/ibm/ EJBs websphere / asynchbeans / package-summary.html? resultof =% 22% 61% 73% 79% 6E% 63% 68% 62% 65% 61% 6E% 22% 20% 22% 75% 73% 65% 72% 74 % 72% 61% 6E% 73% 61% 63% 74% 69% 6f% 6E% 22% 20% 22% 75% 73% 65% 72% 74% 72% 61% 6E% 73% 61% 63% 74 20% 22%

Toutes mes excuses pour les liens non fonctionnels - Je suis un nouvel utilisateur et ne peut donc afficher deux liens de travail

.

Bougez vieilles MBeans simples tombent dans l'une de ces catégories, du point de vue d'IBM?

Fait intéressant, le UserTransaction semble être disponible sur JNDI « JTA / UserTransaction » et en utilisant que comme une option de repli semble fonctionner - mais:

  • WAS 7 est compatible Java EE 5 et à partir de J2EE 1.3 'java: comp / UserTransaction' est l'emplacement JNDI spécifié pour la UserTransaction - voir la spécification J2EE 1.3 `http://java.sun.com/ j2ee / j2ee-1_3-fr-spec.pdf

  • En utilisant une recherche à partir d'une version antérieure de la spécification EE apparaît comme une source potentielle d'autres bugs, et pourrait ne se penchera sur une partie de mon problème - le fait que ÉTAIT pense mon fils de MBean n'est pas associé à une application pourrait causer d'autres problèmes.

Un autre point à noter est que le UserTransaction est également caché aux discussions pour le travail soumis du MBean au gestionnaire de travail de l'application (un gestionnaire de travail IBM) - qui pourrait être parce qu'il est le traitement de ce travail comme il est un haricot async présenté par un EJB?

Les explications possibles qui me sont produits à sont:

  • Il pourrait y avoir des problèmes avec la façon dont IBM a mis en place des fils MBean dans ÉTAIT 7 et associé puis avec les applications qui enregistrent les MBeans.

  • Il pourrait y avoir quelques options de configuration supplémentaires pour l'enregistrement MBean qui permettrait WAS savoir qu'il devrait associer le MBean avec l'application qui l'a enregistré. Je l'ai essayé plusieurs approac alternativesEME, mais a vu la même exception à chaque fois:

    • Enregistrement des MBeans avec des descripteurs XML et UserCollaborators

    • les Enregistrement avec ModelMBeanInfo

    • les enregistrer auprès de l'AdminService plutôt que le MBeanServer

    • Amélioration de la ObjectName pour le MBean avec des propriétés supplémentaires (demande, J2EEApplication) lors de l'inscription

  • Il pourrait y avoir quelques options de configuration supplémentaires pour la demande client JMX qui permettrait WAS savoir qu'il devrait associer le invokation MBean avec l'application appropriée. Ce poste forum suggère qu'il est possible de configurer une application cliente d'avoir accès au contexte initial: `http://www.ibm.com/developerworks/forums/thread.jspa?messageID=14021995

  • Je pourrais tout simplement pas être censé essayer d'utiliser MBeans de cette façon - malgré les déclarations d'IBM que je devrais être capable. Il a été suggéré que la solution sont EJBs appropriée pour ce genre d'exigence.

Toute lumière qui peut être versé sur ce problème serait grandement apprécié.

Était-ce utile?

La solution

MBeans exécuter sur un thread séparé de votre application, donc ils n'ont pas accès au contexte de nommage de l'application dans JNDI, et par conséquent, ils n'ont pas accès à votre UserTransaction.

Je pense que votre explication potentielle finale est probablement le plus précis:

Je pourrais tout simplement pas être censé essayer d'utiliser MBeans de cette façon - malgré les déclarations d'IBM que je devrais être capable. Il a été suggéré que la solution sont EJBs appropriée pour ce genre d'exigence.

MBeans peut ne pas être approprié pour ce type de travail. Au contraire, à l'aide ou un service EJB Web pourrait être plus approprié.

Autres conseils

Vous devez définir TransactionManagementType.BEAN sur transactionManagement comme ceci: 

@TransactionManagement(TransactionManagementType.BEAN)
Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top