7 Replies Latest reply on Jan 28, 2008 6:16 AM by (Jerry_Helbling)

    Apparent port conflict using LCDS with JBoss

      Hi,<br />I am somewhat new to this so please bear with me.  On my server I have lcds installed and sample.war working in JBoss 4.0.5.  I have written a datatier in Java against PostgreSQL 8.x and am writing simple mxml programs to test it.  I have had some success with this. All of the new code is installed in a copy of samples.war because I do not understand the configuration files well enough to toss the examples out.  My latest problem is that my recent versions of the war file get this error in my JBoss log file:<br />Exception in thread "RTMP-Server" <br />flex.messaging.endpoints.rtmp.RTMPException: The RTMP server has encountered a fatal exception starting up: Address already in use<br />     at flex.messaging.endpoints.rtmp.BaseNIORTMPServer.run(BaseNIORTMPServer.java:317)<br />     at java.lang.Thread.run(Thread.java:595)<br />The port specified in the services-config.xml in my war is 2038, and I see JBoss also has an identical services-config.xml at:<br /> <jboss root>/server/default/flex/WEB-INF/flex.  <br />Has anyone else seen this?  Do I just need to change the port?  In both places?  Or is there something else I need to do?<br />Thanks!
        • 1. Re: Apparent port conflict using LCDS with JBoss
          Robert Hirst Level 1
          Can you see flex.war file in your JBoss deploy folder?
          • 2. Re: Apparent port conflict using LCDS with JBoss
            Level 1
            Yes, it did contain flex.war, so I removed it and I still got:
            The RTMP server has encountered a fatal exception starting up: Address already in use

            I think the idea that there are redundant wars or jars is probably relevant here. For example I also got:
            LogConfigurationException: Invalid class loader hierarchy. You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed.

            Thanks for that suggestion. Any other ideas?
            • 3. Re: Apparent port conflict using LCDS with JBoss
              Robert Hirst Level 1
              Is there a "RTMP server started successfully" type message higher up? Are there any clues as to what war/ear is being deployed when the first instance starts successfully?

              If it's the samples.war loading when the first instance of the RTMP server, then there may be two declarations in the same set of config files which are causing the conflict. If it's another archive then it may be that causing the problem. And if it's neither, then do a netstat -ab and check the port is free before the server starts.
              • 4. Re: Apparent port conflict using LCDS with JBoss
                Level 1

                Thanks for the comprehensive reply. I think you have hit on the answer.
                I shut down JBoss and tried netstat -a, and found no mention of 2038, so this conflict is a pure Flex and/or lcds problem. Next I removed my war from the deploy directory and restarted JBoss. There was no RTMP error in the log this time. As I said in my original post I based my war on 'samples.war', so obviously the conflict is between samples.war and my war. Finally I removed samples.war and put my war back and it loaded fine. The only important exception left is the

                Thanks for your help,
                • 5. Re: Apparent port conflict using LCDS with JBoss
                  Level 1
                  I am having trouble getting my flex war file to work when I create it using Ant, even though the same war works fine when I create it from my Eclipse Export War function. This is a critical problem and any ideas or suggestions would be greatly appreciated.

                  I have a working installation of LCDS running under JBoss 4.0.5 (in a CENTOS (Red Hat) environment). I have implemented a datatier in Java to interact with my PostgreSQL 8.x database. The Java code, plus the necessary flex jars and xml files and some mxml test programs, are all in an Eclipse J2EE project that I created from the flex samples.war file. It all works fine when I use Eclipse to create a WAR from the project and deploy it in JBoss. My problem is this: When I create a WAR piece by piece using Ant, then deploy it to JBoss, that WAR does not work. The error I get is this:
                  javax.servlet.ServletException: Invalid Configuration: see previous failures. flex.webtier.util.ServiceUtil.setupFlexService(ServiceUtil.java:55) flex.webtier.server.j2ee.MxmlServlet.init(MxmlServlet.java:57), etc.

                  When I look at the log I see this problem:
                  "You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed.",
                  but that error is in the server log even when I use the good WAR file.
                  Thanks in advance!
                  • 6. Re: Apparent port conflict using LCDS with JBoss
                    Robert Hirst Level 1
                    Can you see any difference in internal structure between the 2 war files?

                    Since they are just zip files you should be able to manually open them with a compression utility and do a quick visual inspection of the files and folders, particularly checking for missing files or difference in hierarchy.

                    It may be that the Ant script is leaving some critical files out, or placing them in the wrong location.

                    If possible, can you post your build.xml file?
                    • 7. Re: Apparent port conflict using LCDS with JBoss
                      Level 1

                      Thanks for responding. Here is my Ant script, comments and all.

                      <?xml version="1.0" ?>
                      <project default="main" >
                      <!-- basedir. Hmm. we could actually put this Ant script IN THE ROOT of the sbda eclipse project, as it is mapped to svn.
                      Then we could have a separate script that checks out all of that stuff from svn, cd's to the root of the checked out
                      code, then runs Ant. In that case the basedir IS ".", because it is all run relative to wherever that checked out
                      code will lives. This also gets this script into ANT, which is a safe place for it.
                      So where does the 'first' script live? We have to use it before we check out from svn...

                      And what about the php code to handle uploads, sb_upload.php? For now that is separate, not directly in svn.
                      At least until we can get the eclipse for php to also use Subclipse.

                      Note: we also need to do a plain vanilla copy of the WEB-INF from basedir to the war dir. We do NOT wish
                      to create the WEB-INF from scratch!!

                      <taskdef name="svn" classname="org.tigris.subversion.svnant.SvnTask"> </taskdef>

                      <target name="main" depends="checkout, initvars, initdirs, compile, war, deploy"/>
                      <target name="mainxxxx" depends="initvars, compile"/>
                      <property name="checkout_target" value="C:\dev\sb\BuildScience\ant_dev\root3"/>
                      <property name="checkedout_project" value="${checkout_target}"/>

                      <target name="checkout" >
                      <svn javahl="true" description="use svn-ant to checkout from our svn -- destPath is 'basedir' for all else">
                      <checkout url="http://sb001.com/dev/sbda"

                      <target name="initvars">
                      <property name="src" value="${checkedout_project}/src"/> <!-- this works! -->
                      <property name="bin" value="${checkedout_project}/output"/> <!-- this works! First we compile to 'bin', then later copy to WEB-INF/classes. Yes.-->
                      <property name="web" value="${checkedout_project}\WebContent"/> <!-- this works! Because all of the webby stuff (in our case the mxml and as in their folders) IS at basedir-->
                      <property name="descriptors"
                      <property name="wardir" value="${checkedout_project}/output/war"/>
                      <property name="warfile" value="sbda.war"/>
                      <property name="warfinaldir" value="${checkedout_project}/finalwar"/>
                      <property name="deploydir" value="${checkedout_project}/fakojbossdeploydir"/>
                      <property name="morejarsdir" value="${web}\WEB-INF\lib"/>
                      <property name="morejarsdir2" value="${web}\WEB-INF\flex\jars"/>
                      <echo> "checkout_target is: ${checkout_target}" </echo>
                      <echo> "checkedout_project is: ${checkedout_project}" </echo>
                      <echo> "src is: ${src}" </echo>
                      <echo> "bin is: ${bin}" </echo>
                      <echo> "web is: ${web}" </echo>
                      <echo> "descriptors is: ${descriptors}" </echo>
                      <echo> "wardir is: ${wardir}" </echo>
                      <echo> "warfile is: ${warfile}" </echo>
                      <echo> "warfinaldir is: ${warfinaldir}" </echo>
                      <echo> "deploydir is: ${deploydir}" </echo>
                      <echo> "morejarsdir is: ${morejarsdir}" </echo>
                      <echo> "morejarsdir2 is: ${morejarsdir2}" </echo>

                      <path id="classpath">
                      <fileset dir="${morejarsdir}" includes="**/*.jar"/>
                      <fileset dir="${morejarsdir2}" includes="**/*.jar"/>

                      <target name="initdirs">
                      <!-- <mkdir dir="${wardir}/WEB-INF"/> MUST do a straight copy of this from basedir. Do NOT create from scratch.-->
                      <mkdir dir="${wardir}/WEB-INF/classes"/> <!-- But this one is a keeper, since our WEB-INF does NOT have a classes directory. -->
                      <!-- A new directory: a place to put the finished WAR file -->
                      <mkdir dir="${warfinaldir}" />
                      <mkdir dir="${deploydir}" />


                      <!-- Looks good. Will compile from 'src' and place the results in 'bin', which is /output. The war target will copy them from there to the appropriate place in the WAR file.
                      Damn. javac cannot find our classpath lib. It should be able to figure out the Postgres and Flex stuff but it does not yet. This classpath ref is the likeliest culprit.
                      <!-- <target name="compile">
                      <javac destdir="${bin}" srcdir="${src}" includes="**/*.java" classpathref="classpath" verbose="true" />
                      </target> -->
                      <target name="compile">
                      <javac destdir="${bin}" srcdir="${src}" includes="**/*.java" verbose="true" >
                      <fileset dir="${morejarsdir}">
                      <include name="**/*.jar"/>
                      <fileset dir="${morejarsdir2}">
                      <include name="**/*.jar"/>
                      <!-- <classpath refid="build.classpath" /> -->

                      <target name="war">
                      <!-- This big copy will also copy all of the supporting flex stuff we need, especially the stuff in WEB-INF/flex (in svn) -->
                      <copy todir="${wardir}">
                      <fileset dir="${web}" >
                      <include name="**/*.*" />
                      <exclude name="**/junit.jar" />
                      <exclude name="**/javax.servlet.jar" />
                      <exclude name="**/commons-logging.jar" />
                      <!-- <exclude name="**/postgresql-8.1-410.jdbc3.jar" /> -->
                      <!-- postgresql-8.1-410.jdbc3.jar junit.jar javax.servlet.jar -->

                      <!-- <copy file="${descriptors}/web.xml" todir="${wardir}/WEB-INF" /> Don't need this because the web.xml file will be capied by the previous copy step.-->
                      <!-- Copy the class files to the special location in the war file -->
                      <copy todir="${wardir}/WEB-INF/classes">
                      <fileset dir="${bin}" includes="**/*.class" />
                      <fileset dir="${src}" >
                      <!--<include name="**/*.java"/> -->
                      <!-- Very special inclusion: This line will pull in commons-logging.properties from the root of 'src' dir
                      We absolutely MUST have it to fix Adobe FDS bug 179227 which will otherwise cause the war to fail in JBoss with an error like:
                      "Caused by org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy. You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed."
                      In fact we don't need the Java files but we need this!
                      <include name="**/*.properties"/>
                      <!-- war it up: -->
                      <jar jarfile="${warfinaldir}/${warfile}" basedir="${wardir}" />

                      <target name="deploy">
                      <copy file="${warfinaldir}/${warfile}" todir="${deploydir}" />

                      <!-- <target name="ear">
                      <copy file="${descriptors}/application.xml" todir="${eardir}/META-INF" />

                      <jar jarfile="${basedir}/${earfile}" basedir="${eardir}" />