Проблемы при переходе с кода, связанного с JRun, на Tomcat - ColdFusion 8 на ColdFusion 2016 - PullRequest
Новая
       53

Проблемы при переходе с кода, связанного с JRun, на Tomcat - ColdFusion 8 на ColdFusion 2016

0 голосов
/ 02 мая 2018

Мы пытаемся перейти с ColdFusion 8 на ColdFusion 2016 и у нас возникли проблемы с переносом некоторых пользовательских Java-сервисов, которые давно были созданы кем-то другим. Чтобы облегчить загрузку / запуск / общение ColdFusion со Службами, они были написаны на Java и использовали JRun в качестве зависимости.

Я полагаю, что интерфейс jrunx.kernel.ServiceMBean сначала расширяется, чтобы определять любые вызовы функций, которые ColdFusion будет иметь для вызова (т. Е. Доступ к API из ColdFusion-> Java). 

public interface MyMBean
  extends ServiceMBean {

    /**
     * Adds a Request object to the RequestList
     */
    public boolean addRequest(String destination, String body, etc.);

    // etc.
}

Затем этот интерфейс реализуется путем расширения jrunx.kernel.ServiceAdapter и реализации интерфейса MyMBean выше и java.lang.Runnable. Я считаю, что именно это «делает код сервисом», с которым ColdFusion может работать / разговаривать, а затем приступает к реализации пользовательского кода (включая определенные выше вызовы API, управление различными потоками и т. Д.), А также реализует сервис-ориентированные методы. для таких вещей, как start() и stop(), когда ColdFusion запускает / останавливает службу, которая предположительно ServiceMBean или ServiceAdapter требует. 

/**
 * Main class
 */
public class MyService extends ServiceAdapter
    implements MyMBean, Runnable {

    // Declare various custom member variables

    /**
     * Invoked as soon as this class is called
     */
    public void init() { ... }

    /**
     * Invoked when this service is started
     */
    public void start() { ... }

    /**
     * Invoked when this service is stopped
     */
    public void stop() { ... } 

    /**
     * Run the service
     */
    public void run() { ... }

    // Custom functions, etc.
}

После компиляции файл MyPackage.jar помещается в C:\ColdFusion8\runtime\lib\, а затем регистрируется в C:\ColdFusion8\runtime\servers\coldfusion\SERVER-INF\jrun.xml, чтобы сообщить ColdFusion о загрузке службы. 

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE jrun-server PUBLIC "-//Macromedia, Inc.//DTD jrun-server 4.0//EN" "http://jrun.macromedia.com/dtds/jrun-server.dtd">
<jrun-server>

    <!-- Various ColdFusion Core Services -->
    <!-- ...etc --->

    <!-- Register MyService --->
    <service class="jrunx.MyPackage.MyService" name="MyService">
        <attribute name="bindToJNDI">true</attribute>
        <attribute name="activeHandlerThreads">25</attribute>
        <attribute name="maxHandlerThreads">1000</attribute>
        <attribute name="minHandlerThreads">20</attribute>
        <attribute name="threadWaitTimeout">180</attribute>
        <attribute name="timeout">600</attribute>
    </service>

</jrun-server>

Чтобы позволить ColdFusion «вызывать вызовы API», раскрытые в реализации ServiceMBean, мы использовали простой код, такой как: 

<cfset scheduler = initContext.lookup("jrun:service/SchedulerService")> 
<cfset schedulerRoot = XmlParse(scheduler.getServerStatus())>

Мы понимаем, что хотя ColdFusion 8 был основан на JRun, он был отброшен в пользу Tomcat, поэтому мы ожидаем, что нам потребуется обновить код Java (а именно объявления интерфейса службы JRun для ServiceMBean и ServiceAdapter) для совместимости с эквивалентными сервисами Tomcat. Затем, наконец, нам нужно найти новый способ регистрации его в ColdFusion 2016 (я подозреваю, в Tomcat в C:\ColdFusion2016\cfusion\runtime\conf\servers.xml или C:\ColdFusion2016\cfusion\runtime\conf\web.xml?).

Если это актуально, есть три реализации, абстрагированные как «MyService» выше: 1. «DirectoryWatcherService» - наблюдает за папкой для файлов, которые появляются, а затем вызывает ColdFusion, чтобы что-то с ним сделать 2. «SchedulerService» - наблюдает за базой данных в течение запланированной даты / времени для передачи и затем вызывает ColdFusion, чтобы что-то с ним сделать 3. «GatewayService» - позволяет ColdFusion отправлять ему сообщение для доставки по постоянному TCP-соединению сторонней службе. Он также прослушивает входящие запросы от шлюза, а затем вызывает ColdFusion, чтобы что-то сделать с данными.

...