Искание JNDI для The JTA User Trantransaction недоступна для MBEAN Threads в WebSphere Application Server 7

Question

Я пытаюсь вызвать бизнес -логику через JMX (используя «стандартные» mbeans) в веб -приложении в WebSphere Application Server 7 с включенным JTA и хотела бы знать, почему эта бизнес -логика не видит Trater Transaction, когда вы вызываете из MBEAN (потому что это может при вызове через пользовательский интерфейс веб -приложения).

Когда Hibernate пытается найти пользовательский перевод через «Java: Comp/Usertransaction», следует следующее исключение:

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

Эта проблема выглядит так, как будто это больше, чем просто проблема конфигурации Hibernate - Hibernate ищет пользовательский перевод на то, что IBM говорит, что это правильное местоположение jndi ('java: comp/usertransaction') - см. Этот инфектор документа.

Кроме того, я могу воспроизвести проблему в простом веб -приложении, в котором есть MBEN, который выполняет поиск:

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);
    }
  }

и слушатель контекста, который вызывает поиск во время запуска, а затем регистрирует MBEN:

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);
    }
}

Поиск «Java: Comp/Usertransaction» преуспевает во время инициализации контекста, но сбой (с аналогичным трассировкой стека к этому выше), когда вы вызываете через JMX, как так:

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

А «Расширение административной системы сервера приложений WebSphere с помощью пользовательского документа MBEAN». В Infocenter's IBM предполагает, что стандартные MBEAN, которые были проверены в приложениях за пределами за пределами, должны работать.

IBM DO утверждает, что поиск пользователя не доступен:

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

• Async Feans, созданные EJBS `http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.javadoc.doc/web/apidocs/com/ibm/websphere/asynchbeans/package- Summary.HTML? %73%61%63%74%69%6F%6E%22%20%22%75%73%65%72%74%72%61%6E%73%61%63%74%22%20

Приносим извинения за нефункциональные ссылки - я новый пользователь, и поэтому могу опубликовать только две рабочие ссылки.

Пластые старые mBeans попадают в одну из этих категорий с точки зрения IBM?

Интересно, что пользовательский перевод, по -видимому, доступен на JNDI Lookup 'JTA/USERTRANCACTION', и использование этого в качестве резервной опции, кажется, работает, но::

• 7- это Java EE 5, а по состоянию на J2EE 1.3 'Java: Comp/UserTransaction'- указанное местоположение JNDI для пользовательского транзакции- см. fr-spec.pdf

• Использование поиска из более ранней версии спецификации EE кажется потенциальным источником других ошибок и может решить только часть моей проблемы - тот факт, который думает, что поток моего MBEN не связан с приложением, может вызвать другие проблемы.

Еще один момент, который следует отметить, заключается в том, что пользовательский перевод также скрыт к потокам для работы, представленной от MBEN на работу менеджера по работе с приложением (менеджер IBM) - что может быть связано с тем, что он относится к этой работе, как будто это асинхровый бон, поданный EJB?

Возможные объяснения, которые мне произошли:

• Там могут проблемы с тем, как IBM настроила потоки MBEAN, были 7, а затем ассоциируются с приложениями, которые регистрируют MBEAN.

• Для регистрации MBEAN могут быть некоторые дополнительные параметры конфигурации, которые могли бы знать, что он должен связать MBEN с приложением, которое его зарегистрировало. Я пробовал несколько альтернативных подходов, но каждый раз видел одно и то же исключение:

  • Зарегистрирование MBEAN с помощью UserCollaborators и XML Descriptors

  • Зарегистрирование их с помощью ModelmbeanInfo

  • Зарегистрирование их с помощью Adminservice, а не Mbeanserver

  • Улучшение объекта для MBEAN с помощью дополнительных свойств (приложение, J2EEAPPLICATION) при регистрации

• Для запроса клиента JMX могут быть некоторые дополнительные параметры конфигурации, которые сообщают, что он должен связать вызов MBEN с соответствующим приложением. В этом сообщении на форуме предполагается, что можно настроить клиентское приложение, чтобы иметь доступ к первоначальному контексту: `http://www.ibm.com/developerworks/forums/thread.jspa?messageid=14021995

• Я просто не должен был пытаться использовать Mbeans таким образом - несмотря на заявления IBM, которые я должен быть в состоянии. Было высказано предположение, что EJB являются подходящим решением для такого рода требований.

Любой свет, который можно пролить на эту проблему, был бы очень оценен.

Answer 1

MBEAN работает в отдельном потоке, чем в вашем приложении, поэтому они не имеют доступа к контексту именования приложений в JNDI, и поэтому они не имеют доступа к вашему пользовательскому обращению.

Я думаю, что ваше окончательное потенциальное объяснение, вероятно, является наиболее точным:

Я просто не должен был пытаться использовать Mbeans таким образом - несмотря на заявления IBM, которые я должен быть в состоянии. Было высказано предположение, что EJB являются подходящим решением для такого рода требований.

Mbeans может не подходить для такого типа работы. Скорее, использование EJB или веб -службы может быть более подходящим.

Answer 2

Вы должны установить TransactionManagementType.BEAN На транзакционном управлении, как так:

@TransactionManagement(TransactionManagementType.BEAN)