7 Replies Latest reply on Sep 2, 2004 3:05 AM by genman

    Problem with deployment of non-static *-ds.xml

    sysuser1

      I am trying to deploy a *-ds.xml file which is created on the fly by a servlet. So in my jboss-service.xml, I am deploying a url like http://localhost:8080/dbinfocreator/sybase-ds.xml. I notice that if I do this, even though a call is made to the servlet when jboss server starts, the JNDI binding of the datasource specified in the generated xml is not taking place. I am printing the xml whenever a request is made to the servlet, and I have verified that there is no problem with the generated content.

      On the other hand, if I deploy the same url using the jmx console after server has already started, or deploy the static copy of the generated xml that's obtained from another webserver (e.g. http://otherhost/sybase-ds.xml), everything works fine.

      Is there some kind of race-condition on the server startup that's preventing the jndi deployment? Any ideas/help would be appreciated.

      TIA!

        • 1. Re: Problem with deployment of non-static *-ds.xml

          Moderated: Your question is unanswerable since you don't explain how you deploy the url.

          • 2. Re: Problem with deployment of non-static *-ds.xml
            sysuser1

            I am deploying the url by adding it to URLDeploymentScanner mbean in jboss-service.xml as follows:

            <attribute name="URLs">
             deploy/,
             http://localhost:8080/sybase-ds.xml,
             </attribute>

            The sybase-ds.xml is created on the fly by a servlet. I found that the FileWatcher keeps trying to access this url every 5 sec, as expected. First few tries to access this url fail since the webserver is not up by then. After webserver is up, the file is accessed successfully (this is verified from log) but after this, the XslSubDeployer does not kick in and the contents are not deployed. If I point the url to an external webserver, which is already running, then deployment works fine.


            To get rid of this problem, I also tried to generate the *-ds.xml using a custom protocol handler (instead of using http) as follows:

            <attribute name="URLs">
             deploy/,
             myprotocol://sybase-ds.xml,
             </attribute>

            This approach works fine and the datasources are created, but I get an error like the following in the log:
            18:12:23,868 WARN [SARDeployer] Failed to add deployable jar: file:<jboss-home>/tmp/deploy/tmp14340"

            The tmp file in the error message contains the xml file resulting from the custom protocol handler.

            The whole idea behind this approach is that due to some issues with deployment procedures, we don't want the *-ds.xml file to be written to disk. Please enlighten me on these issues as our scheduled date to move from weblogic to jboss is very close now. Let me know if you need any additional information to diagnose the problem.

            Thanks,
            Raman



            • 3. Re: Problem with deployment of non-static *-ds.xml
              anil.saldhana



              deploy/,
              myprotocol://sybase-ds.xml



              Don't add comma after sybase-ds.xml


              The only way to achieve this is having an external tomcat instance providing you with the ds file. The jboss-service file gets deployed right at the beginning. Your approach to do a http url scrape for the sybase-ds.xml is fine. No issue. But you are trying to get the ds file out of Tomcat instance running on Jboss, which will be deployed much later.

              Have a standalone tomcat instance running on the same box providing the ds.file

              • 4. Re: Problem with deployment of non-static *-ds.xml
                anil.saldhana

                Raman, I want to add that you are trying to make things complicated. The easiest solution is to have a -ds file generated or placed in the deploy directory.

                If not, have a seperate webserver on the machine.

                • 5. Re: Problem with deployment of non-static *-ds.xml
                  sysuser1

                  Thanks for your reply janilsal.

                  The reason for following this approach is following:

                  1. We can't have a static ds.xml file since the database parameters are different depending upon the configuration provided at the server startup (we have multiple instances of jbosss running for different services)

                  2. We can't afford to have an external tomcat server generating this xml since anyone can connect to that server using http and get the password information. In fact, this was another reason we preferred custom protocol over http as our custom protocol is not accessible to someone outside the jvm.

                  We see that -ds.xml file is finally accessible to jboss after tomcat service has come up, the problem is that this does not get deployed as mentioned in the previous mail.

                  It's also not clear to me why I get the exception " [SARDeployer] Failed to add deployable jar: file:<jboss-home>/tmp/deploy/tmp5314" only while using my custom protocol handler, and not while using http.

                  Is there a way to spcify that the url containing -ds.xml is deployed only after tomcat service has come up?

                  Thanks,
                  Raman

                  • 6. Re: Problem with deployment of non-static *-ds.xml
                    sysuser1

                    I got rid of the SARDeployer error after I renamed the url from myprotocol://sybase-ds.xml to something like myprotocol://dummyhost/sybase-ds.xml. The deployer probably wasn't able to get the path from URL and hence it was reporting that error.

                    But now, I have another one :(. I see that all the deployable files are copied over to tmp-dir/deploy directory. This includes the generated -ds.xml file which has all the passwords in it. Is there a way to tell jboss to not copy these files to tmp/deploy directory?

                    Thanks,
                    Raman

                    • 7. Re: Problem with deployment of non-static *-ds.xml
                      genman


                      You can protect this directory for security purposes. Or if you are paranoid:

                      http://www.jboss.org/wiki/Wiki.jsp?page=EncryptingDataSourcePasswords