9 Replies Latest reply on Apr 29, 2016 10:12 AM by Benedict Rasmussen

    Migrating Application from AS7 to WildFly

    Mahesh G Newbie

      Has anybody migrated application from AS7 to any version of WildFly ? We have to migrate our application from AS7 to WildFly 9 or 10 and hence was wondering if anybody has done it and would like to share experiences ?

       

      If anybody is starting or in the middle of it, then too it might be helpful to connect to share our experiences as we move along.

       

      Thanks a ton in advance.

        • 1. Re: Migrating Application from AS7 to WildFly
          Miroslav Novak Master

          You should check Windup Migration Platform tool. Put your deployment into it and it'll generate what needs to be changed to migrate and how hard it will be to change it. It's worth of try.

           

          To migrate your configuration check EAP 7 Migration Guide: https://access.redhat.com/documentation/en/red-hat-jboss-enterprise-application-platform/version-7.0.beta/migration-guide/


          Wildfly 10 offers :migrate operation in CLI. Take your config (standalone...xml) and start Wildfly 10 in admin-only mode with it. Then migrate the 3 subsystems per instructions.

          • 2. Re: Migrating Application from AS7 to WildFly
            Benedict Rasmussen Newbie

            The first thing I would figure out is whether you are going to 9 or 10, as there are some subtle differences. One small thing I liked about 10 was that the management console got a bit of a facelift (having never worked with 9.) You should also figure what JAR versions sit inside the module directories of each. In other words, if you are using HornetQ still and don't plan on upgrading, WF 9 is going to be easier to migrate to because you won't have to tinker with disabling ArtemisMQ in WF 10.

             

            I had to put together a brief, informal doc on WF 9 vs 10 for a project I was assigned a month or so back. I'll quickly overview what I wrote down.

            • Hibernate: WF 9 uses 4.3.10.Final (released May, 2015.) WF 10 uses 5.0.7 (released Jan 2016)
            • Java and Java EE: WF 10 has no support for Java 7. You must use 8 or, supposedly, a beta-build of 9. Both WF 9 and 10 use Java EE 7. If you are coming up from EE 6 (which I believe AS7 uses?), do some research into EJB 3.1 to EJB 3.2. I know 3.0 to 3.1 was a big change, and 3.1 to 3.2 was a small one, but knowing the differences will make a difference.
            • Default Messaging Brokers: WF 9 uses HornetQ-2.4.7. WF 10 uses ArtemisMQ 1.1.0. Please note that Artemis was added late in the development process, and during my recent upgrade I had some difficulties configuring my messaging subsystem... The management console is completely borked for the messaging subsystem.

            I am finishing an upgrade from JBoss 5.1 to WF 10, which are drastically different versions. Your upgrade from 7, which was the first big step towards the architecture that WF now uses, should hopefully be relatively easy. Good luck!

            Oh, and if you have to configure a bridge.... *shudders*

            1 of 1 people found this helpful
            • 3. Re: Migrating Application from AS7 to WildFly
              Justin Bertram Master

              Oh, and if you have to configure a bridge.... *shudders*

              The creation of a bridge (whether JMS or "core") should be pretty straight-forward and not terribly different than previous versions of JBoss AS/Wildfly.  Did you have some trouble with your bridge configuration?

              • 4. Re: Migrating Application from AS7 to WildFly
                Benedict Rasmussen Newbie

                We had a lot of trouble setting up our bridge. Granted, not all of the difficulties we were having were directly related to issues with WF, but some issues were related to WF.

                • All WF documentation talks about is setting up a JMS bridge (which we were trying to do). We tried doing everything through the management console, but the management console can only create a core bridge. This conflicted with the fact that it creates JMS queues.
                • All the "Need help?" messages on the messaging subsystem on the management console are broken- they display no information. Fortunately we found this link that helped tremendously: Wildfly Model Reference
                • Artemis documentation tended to conflict the WF documentation. The Artemis documentation specifically mentions that core bridges should always be used in favor over JMS bridges. "Always use a core bridge if you can in preference to a JMS bridge." The WF documentation doesn't say anything about a JMS bridge vs a core bridge, or really make any mention of core bridges (or queues, for that matter) at all.
                • WF documentation talks about using Netty, but no information about including Netty in the configuration is given.
                • No information is mentioned regarding setting up a bridge to a remote server, which includes setting up a connector and a socket-binding.

                We were just really surprised when trying to research our issues because it was almost as if no one had set up a JMS bridge in WF to a remote server. The following is what we eventually ended up with (with "sensitive" information removed, of course):

                 

                Sender

                 

                <subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0">

                ...

                <connector name="bridge-connector" factory-class="org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnectorFactory" socket-binding="messaging-remote">

                    <param name="host" value="myRemoteServer"/>

                    <param name="port" value="PortValue"/>

                </connector>

                ...

                <connection-factory name="RemoteConnectionFactory" entries="java:jboss/exported/jms/RemoteConnectionFactory" connectors="bridge-connector"/>

                ...

                <jms-bridge name="myBridgeName" max-batch-time="100" max-batch-size="10" max-retries="-1" failure-retry-interval="10000" quality-of-service="AT_MOST_ONCE">

                    <source destination="queue/localQueue" connection-factory="localConnectionFactory" />

                    <destination password="pass" username="user" destination="queue/remoteServerQueue" connection-factory="/jboss/exported/jms/RemoteConnectionFactory"

                </jms-bridge>

                </subsystem>

                ...

                <outbound-socket-binding name="messaging-remote">

                    <remote-destination host="myRemoteServer" port="PortValue"/>

                </outbound-socket-binding>

                 

                 

                Receiver

                 

                <subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0">

                ...

                <acceptor name="netty-acceptor" factory-class="org.apache.activemq.artemis.core.remoting.impl.netty.NettyAcceptorFactory" socket-binding="myBridgeName-inbound">

                    <param name="host" value="server's.ip.address" />

                    <param name="port" value="samePortValueAsAbove" />

                </acceptor>

                ...

                </subsystem>

                 

                <socket-binding name="myBridgeName-inbound" port="SamePortValue" fixed-port="false"/>

                • 5. Re: Migrating Application from AS7 to WildFly
                  Justin Bertram Master
                  • All WF documentation talks about is setting up a JMS bridge (which we were trying to do). We tried doing everything through the management console, but the management console can only create a core bridge. This conflicted with the fact that it creates JMS queues.
                  • All the "Need help?" messages on the messaging subsystem on the management console are broken- they display no information. Fortunately we found this link that helped tremendously: Wildfly Model Reference

                  I assume you're talking about the GUI Web-based console rather than the command-line console.  I've never used the web-console so I can't really speak to either of these points.

                   

                  • Artemis documentation tended to conflict the WF documentation. The Artemis documentation specifically mentions that core bridges should always be used in favor over JMS bridges. "Always use a core bridge if you can in preference to a JMS bridge." The WF documentation doesn't say anything about a JMS bridge vs a core bridge, or really make any mention of core bridges (or queues, for that matter) at all.

                  There's lots of things in the Artemis documentation that isn't also in the Wildfly documentation.  The Wildfly documentation isn't meant to rehash the subsystem documentation so that's not too surprising.

                   

                  • WF documentation talks about using Netty, but no information about including Netty in the configuration is given.

                  Netty connections are used by default, but that is probably obscured a bit behind the http-acceptor and http-connector because they use an upgrade mechanism to move from an HTTP connection to a Netty connection.

                   

                  • No information is mentioned regarding setting up a bridge to a remote server, which includes setting up a connector and a socket-binding.

                  You're certainly free to configure local Artemis connection factories that point to remote servers (using a specific connector and socket-binding) and then use those connection factories in your JMS bridge configuration, but that's not the normal configuration for a JMS bridge (which is probably one reason why it's not mentioned in the documentation).  The JMS bridge is meant to be generic so it can inter-operate with other JMS providers (i.e. not Artemis) and so it can be configured with all the information that a normal JMS client would use to connect to a remote broker (i.e. connection factory JNDI lookup, queue JNDI lookup, and JNDI properties to connect to the remote JNDI provider).  There's no strict need to configure a new connector and socket-binding.  You simply need to specify the appropriate JNDI properties to point the bridge to the appropriate remote provider.

                  • 6. Re: Migrating Application from AS7 to WildFly
                    Miroslav Novak Master

                    To deploy JMS Bridge to Wildfly 10/EAP 7 which will move messages from HornetQ from AS 7/WF8/9 or EAP6 to Artemis, it is necessary to do following things.

                     

                    First backup everything :-)

                     

                    Then on WF10/EAP7 side configure JMS Bridge like:

                     <subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0">
                                <server name="default">
                                    ...
                                    <connection-factory name="InVmConnectionFactory" factory-type="XA_GENERIC" entries="java:/ConnectionFactory" connectors="in-vm"/>
                                    ...
                                </server>
                                <jms-bridge name="myBridge" add-messageID-in-header="true" max-batch-time="100" max-batch-size="10" max-retries="-1" failure-retry-interval="1000" quality-of-service="AT_MOST_ONCE" module="org.hornetq">
                                    <source destination="jms/topic/InTopic" connection-factory="jms/RemoteConnectionFactory">
                                        <source-context>
                                            <property name="java.naming.factory.initial" value="org.jboss.naming.remote.client.InitialContextFactory"/>
                                            <property name="java.naming.provider.url" value="remote://127.0.0.1:4447"/>
                                        </source-context>
                                    </source>
                                    <target destination="jms/queue/OutQueue" connection-factory="java:/ConnectionFactory"/>
                                </jms-bridge>
                            </subsystem>
                    

                     

                    Because JMS Bridge needs classes to make connection to HornetQ, it's using org.hornetq module. It's necessary to create this module and it's direct dependencies in WF10/EAP7. org.hornetq module might have dependency to org.jboss.netty module which is not present in WF10/EAP7. Don't use org.hornetq.client module, it does not have to work.

                     

                    To create org.hornetq module, copy those 2 modules from AS7/WF8/9/EAP 6 to WF10/EAP7 modules:

                    ${AS7/WF8/9_HOME}/modules/system/layers/base/org/hornetq/ to ${WF10}/EAP7/modules/system/layers/base/org/
                    ${AS7/WF8/9_HOME}/modules/system/layers/base/org/jboss/netty/ to ${WF10}/EAP7/modules/system/layers/base/org/jboss/
                    

                     

                    Now just make sure that AS7/WF8/9/EAP6 contains configuration for RemoteConnectionFactory for example like:

                    <connection-factory name="RemoteConnectionFactory">
                                            <factory-type>XA_GENERIC</factory-type>
                                            <connectors>
                                                <connector-ref connector-name="netty"/>
                                            </connectors>
                                            <entries>
                                                <entry name="java:jboss/exported/jms/RemoteConnectionFactory"/>
                                            </entries>
                                            <ha>true</ha>
                                            <block-on-acknowledge>true</block-on-acknowledge>
                                            <retry-interval>1000</retry-interval>
                                            <retry-interval-multiplier>1.0</retry-interval-multiplier>
                                            <reconnect-attempts>-1</reconnect-attempts>
                                        </connection-factory>
                    

                     

                    Now just double check that you provided correct names for queues/topics, url for JNDI lookup and in case that you have configured security on AS7/WF8/9/EAP6, also provide correct user names and password for JNDI lookup in source-context and for creating connection to source tag to configuration of JMS Bridge. Also make sure that you've deployed all destinations in WF10/EAP 7 server.

                     

                    Start both of the servers so bridge can do its job.

                     

                    Note: In case that you have EAP 6.4.x.CP then make sure that you copy "org.hornetq" module from .overlays directory. For example: $JBOSS_HOMEmodules/system/layers/base/.overlays/layer-base-jboss-eap-6.4.7.CP/org/hornetq/ and the you remove line:

                    <resource-root path="../../../../../org/hornetq/main/lib"/>
                    

                     

                    from module.xml.

                    • 7. Re: Migrating Application from AS7 to WildFly
                      Mahesh G Newbie

                      brasmussen . Thanks. We have decided to move to WF9 from AS7. How much efforts did you have to put in to migrate from AS5 to WF10 in terms of person days. We are doing estimation and hence it might be helpful.

                      • 8. Re: Migrating Application from AS7 to WildFly
                        Mahesh G Newbie

                        Thanks you all for your support. Since we have decided to go ahead with WF9 I am going to start another thread for migration applications from JBoss AS7 to WF9.

                        • 9. Re: Migrating Application from AS7 to WildFly
                          Benedict Rasmussen Newbie

                          Mahesh G wrote:

                           

                          brasmussen . Thanks. We have decided to move to WF9 from AS7. How much efforts did you have to put in to migrate from AS5 to WF10 in terms of person days. We are doing estimation and hence it might be helpful.

                          Keeping in mind I was developing as a 1-man team, and that my work also included updating old jars and the like... and also considering I came into the project with virtually no knowledge of application servers (I am still a fairly young dev), it has taken me about two months so far between research and development. Now knowing more of what I am doing, I would expect a second effort to go much much more quickly. It will definitely help you that you are moving from 7 to 9 instead of from 5. As I mentioned above, AS7 is similar in many ways to WF.