12 Replies Latest reply on Aug 16, 2007 10:29 PM by bogusexception

    Managing JBoss programmatically?

      What config files can be managed programmatically, and which require file system access?

      For example, in ./server/default/deploy/jms/jbossmq-destinations-service.xml there are the JMS queues and topics. Is the only way to add, edit or remove queues and topics to edit this file manually on the file system, or can I do this from an app running inside the same container?

      In the ./server/default/deploy directory, files are automatically interpreted into the running configuration, but how can I add or remove files in the JBOSS_HOME directory structure from an application running within the app server itself?

      Another example would be how to create an EJB JAR programmatically (that is, from an app running inside the container), then copy it to the deploy directory?

      TIA!


        • 1. Re: Managing JBoss programmatically?
          peterj

          1) You should not modify the configuration files in place while the application server is running. Instead, copy the one you want to modify to a temporary location, edit it there, and then copy back to deploy. Note that the filesin server/xxx/conf are read only on startup. Not sure that you mean by "file system access", the app server needs access rights to all the configuration files.

          2) To deploy your own destinations, create a *-service.xml file, such as mydests-service.xml, and place the queue and topic descriptions in there. Copy the file to the deploy directory to deploy them, and delete it from there to undeploy them.

          3) I am not sure I understand what you are asking, but I think you want to deploy an exploded directory. You can then easily add/update/remove filesi n your application. See http://wiki.jboss.org/wiki/Wiki.jsp?page=ExplodedDeployment.

          4) You can creat a JAR and deploy it programmatically, but I do not have an example.

          • 2. Re: Managing JBoss programmatically?

            PeterJ,

            Thanks for writing! My answers/reply inline:

            1) You should not modify the configuration files in place while the application server is running. Instead, copy the one you want to modify to a temporary location, edit it there, and then copy back to deploy. Note that the files in server/xxx/conf are read only on startup. Not sure that you mean by "file system access", the app server needs access rights to all the configuration files.

            Excellent advice. Looking at the files in that directory, they don't appear to be application, connector, or datasource specific. I've noticed this about ./server/xxx/lib as well.

            2) To deploy your own destinations, create a *-service.xml file, such as mydests-service.xml, and place the queue and topic descriptions in there. Copy the file to the deploy directory to deploy them, and delete it from there to undeploy them.


            Excellent. SO I can make as many as I like, providing they have the correct suffix. Is there a reference listing all of these file suffixes, and their corresponding applicability? It would be great to know which runtime config files can be added/removed like this! This is at the core of my question/problem.

            3) I am not sure I understand what you are asking, but I think you want to deploy an exploded directory. You can then easily add/update/remove files in your application. See http://wiki.jboss.org/wiki/Wiki.jsp?page=ExplodedDeployment .

            The above is really the same as the below:

            4) You can creat a JAR and deploy it programmatically, but I do not have an example.

            I was curious how to create stateful, statless, message-driven, and other beans programmatically, then deploy them programmatically as well.

            While I look for a solution to this dilemma, the above means to me that it is possible to access the JBoss file system (regardless of OS) from an application inside the container, right?

            Thanks!

            • 3. Re: Managing JBoss programmatically?
              peterj

              Regarding a list of suffixes. This doc page gives some of that information, particularly the bullet list of deployers: http://docs.jboss.com/jbossas/guides/j2eeguide/r2/en/html_single/#ch2.deployers
              A more definitive list can be found in the source at system/src/main/org/jboss/deployment/DeploymentSorter.java, look at DEFAULT_SUFFIX_ORDER.

              Yes, you can access the JBoss files from an application inside the container, just do not directly create or modify them, always update them in a temporary directory and then move them to the deploy directory. Otherwise the hot deployer might attempt to deploy the file while you are in the middle of creating it.

              By the way, you might find the various system properties created by JBoss handy. To see them, in the jmx-console, choose the MBean jboss:type=Service,name=SystemProperties, and then click the showAll the operation.

              • 4. Re: Managing JBoss programmatically?

                PeterJ,

                Thanks for writing. I understand a lot more about the app server as a result.

                A more definitive list can be found in the source at system/src/main/org/jboss/deployment/DeploymentSorter.java, look at DEFAULT_SUFFIX_ORDER.

                Interesting. It is deprecated, but points to SuffixOrderHelper.java, which then says the values and order were moved:

                Moved this list to org.jboss.deployment.MainDeployer-xmbean.xml so there are no hardcoded defaults.

                So off I go to there, and see a list of suffixes that includes 150:-service.xml, but that list is commented out, and below it:

                <descriptors>
                 <value value="250:.rar,300:-ds.xml,400:.jar,500:.war,550:.jse,650:.ear,800:.bsh"/>
                </descriptors>
                

                ...but -service.xml is now out of the list. Weird! I started out trying to find which configuration files (.xml) could be added to with a unique prefix (like the uncontested abc-ds.xml), but I'm not sure what I've stumbled onto.

                I know that you can add queues and topics with someQueue-service.xml, but the source I found in this journey didn't bear that out.

                If the only system configuration that can be done with XML descriptors is with queues/topics (*-service.xml) and data sources (*-ds.xml), thats fine. I was just curious what they were.

                Thanks again!



                • 5. Re: Managing JBoss programmatically?
                  peterj

                  When I pointed you to the DEFAULT_SUFFIX_ORDER I knew that it was no longer used (though the ordering is still correct). But that is the only place I have found that lists the various suffixes all in one location.

                  Also, the *-service.xml file can be used to deploy any MBean, not just destinations. You can see that in some of the other *-service.xml file. The *-ds.xml is for data sources only (there is an xslt that converts the *-ds.xml into a -service.xml which then defines the 4 or 5 MBeans that make up a data source).

                  • 6. Re: Managing JBoss programmatically?

                    PeterJ,

                    Firstly, thanks for all your help (to at least me) over the past year. It has made things easier for me.

                    I'm still looking for the same thing, even after all these months. I'm still trying to deploy files in arbitrary locations to the JBoss server. They may be services or JAR, EAR or SAR, but I need to pass the class the filename & location, and ask that file be copied to the ./deploy dir.

                    I've been wrestling with outbound JCA, which would call a program on the outside running as the AS user, but outbound JCA seems extremely difficult. I've even read that it may be overkill.

                    What might hold promise is JMX. The key here, though, seems to be overcoming JBoss' inherent security which prevents a deployed app from deploying/controlling apps via JMX.

                    Not a problem, as I can change the server to suit.

                    Any thoughts?

                    TIA!

                    • 7. Re: Managing JBoss programmatically?
                      peterj

                      Let me see if I understand this correctly. You are attempting to write a stand-alone Java application (one not deployed to JBoss AS) that you can use to deploy applications. I assume that this application might not be running on the same host as the app server. And you want to know how to code the application such that the file-to-be-deployed ends up in the server/xxx/deploy directory. Is that correct?

                      I think that JMX is the way to go. Once the file-to-be-deployed appears in the server/xxx/deploy directory the hot deployer will take it over from there.

                      • 8. Re: Managing JBoss programmatically?

                        PeterJ,

                        Thanks for writing, as always!

                        You are attempting to write a stand-alone Java application (one not deployed to JBoss AS) that you can use to deploy applications.


                        Not quite. I'm just looking for ideas as how to do this from within a deployed app on the same server.

                        I think it is becoming clear that having a local application running as the JBoss user and accessed via JCA would be overly complex and perhaps even impractical.

                        What might hold promise is JMX, as you suggest, but through a program like Maven. According to http://mojo.codehaus.org/jboss-maven-plugin/,
                        jboss:deploy Deploys a directory or file to JBoss via JMX
                        , which would seem to fit the bill. Maven has 2 parts, though.. one for JBoss, and the stand-alone portion (command line exes).

                        Anyway, the objective is the same. I'd like to have pre-compiled (EJB3) classes jar'd, sar'd, etc. with any variables needed passed to them (via env, etc.) and copied to the ./deploy dir. Simply put, that has been the objective all along.

                        The rub seems to be getting a deployed app to interact with files outside the container. So to make a simple list of one possible action (we haven't discussed the logically inevitable undeploy) would be:

                        1. An EJB3 bean decides to, or is told to, deploy (for the purposes of this example) an EJB3 bean that will facilitate REGEX matching.
                        2. That bean communicates to an application outside the container (or...?) the name of the file(s) to be deployed, and the text of the match.
                        3. That app brings together the needed package, XML descriptors, env vars (like the regex match string), and creates the jar, sar, war, ear, etc.
                        4. That app then copies the archive to the ./deploy dir.
                        5. Done.

                        Yes, I know regex is a bad example, because you could pass the regex into the class with each request, but for this example we don't want to add that fat to every requesting class to pass via aever MDB... You get the point.

                        So with this strategy I can un-/deploy beans and services programmatically from within the deployed application(s).

                        TIA for any insights! :)

                        Bogus Exception

                        • 9. Re: Managing JBoss programmatically?
                          peterj

                          Two possibilities that I can think of.

                          1) Because your code is running within the server, you can always look up the name of the deploy directory and then copy the resulting EJB jar file to that directory and let the hot deployer pick it up on the next scan. You can determine the deploy directory name by either getting the jboss.server.base.dir system property and adding 'deploy' to it, or by getting the URLs attribute of the jboss.deployment:type=DeploymentScanner,flavor=URL MBean. To undeploy the JAR you would have to delete it.

                          2) You could simply create the EJB jar anywhere and then use the deploy() method on the jboss.system:service=MainDeployer MBean to deploy the JAR file where it is. You can call undeploy() on the same MBean to undeploy it.

                          With method 1, the EJB JAR is redeployed if you restart the server, but with method 2 the EJB jAR is not redeployed on a restart.

                          If I understand you correctly, the JAR files are custom built, generated on the fly, and possibly used only once. In that case, I would opt for option 2.

                          • 10. Re: Managing JBoss programmatically?

                            PeterJ,

                            Thanks for writing.

                            Because your code is running within the server, you can always look up the name of the deploy directory and then copy the resulting EJB jar file to that directory and let the hot deployer pick it up on the next scan.


                            I like this idea, but I think the trick is the copy part. If I can call a program residing on the outside, I can either pass it the parameters needed (preferred), or even have it call a waiting web service for details about deployment.

                            The only question is how to trigger an external program from within the container (as in from an EJB).

                            I appreciate the insight and discussion.

                            Bogus Exception

                            • 11. Re: Managing JBoss programmatically?
                              peterj

                              Why not use the stream classes to do the copying?

                              Or you could use File.rename() to move the JAR for the deploy directory.

                              Also, if you are going to do a copy, it is usually best to copy the file to a temporary location on the same disk partition as the deploy directory, and then move that file to the deploy directory. This prevents weird zip file error that can occur if the hot deploy tries to deploy the JAR before the copy is finished.

                              And just to answer your question, to run an external program use Process.exec(), though within an EJB you should not wait for the process to exit before continuing.

                              • 12. Re: Managing JBoss programmatically?

                                PeterJ,

                                Thanks for writing. I think this thread is closed now thanks to your persistence. I've now just to think of how to pass info to the waiting program to allow it to do its thing.

                                This isn't a problem for this list, though. I think it is more of a design thing. You know, a class' name and the contents of the envs. Jar'ing up and copying (w/ant or manually) is interesting, too. From here it isn't a technical problem, though.

                                Thanks again!

                                Bogus Exception