6 Replies Latest reply on Nov 2, 2006 4:38 AM by garu

    JBossIDE-2.0.0.Beta2 enhancements to support complex Jboss c

    garu

      Hi IDE team,
      first of all let me explain the kind of configuration i'm talking about.
      I?m starting Jboss passing the following properties:
      -Djboss.home.dir=C:/local/jboss
      -Djboss.server.name=ssrv10
      -Djboss.server.base.dir=C:/home/jboss/server
      -Djboss.server.base.url=file:/C:/home/jboss/server

      This means that with a single installation in C:/local/jboss i can have any number of different instances based in C:/home/jboss/server, depending on the server name.
      As an example you can see the log of the start with the above properties:
      19:28:44,296 INFO [Server] Home Dir: C:\local\jboss
      19:28:44,296 INFO [Server] Home URL: file:/C:/local/jboss/
      19:28:44,296 DEBUG [Server] Library URL: file:/C:/local/jboss/lib/
      19:28:44,296 INFO [Server] Patch URL: null
      19:28:44,296 INFO [Server] Server Name: ssrv10
      19:28:44,296 INFO [Server] Server Home Dir: C:\home\jboss\server\ssrv10
      19:28:44,296 INFO [Server] Server Home URL: file:/C:/home/jboss/server/ssrv10/
      19:28:44,296 INFO [Server] Server Log Dir: C:\home\jboss\server\ssrv10\log
      19:28:44,312 DEBUG [Server] Server Data Dir: C:\home\jboss\server\ssrv10\data
      19:28:44,312 INFO [Server] Server Temp Dir: C:\home\jboss\server\ssrv10\tmp
      19:28:44,312 DEBUG [Server] Server Config URL: file:/C:/home/jboss/server/ssrv10/conf/
      19:28:44,312 DEBUG [Server] Server Library URL: file:/C:/home/jboss/server/ssrv10/lib/

      The ports for each instance are set using the server-bindings.xml.
      The jboss-service.xml contains two url deployers, the first that deploys all the system services from the installation C:\local\jboss\default or all configurations, the second one, depending on the first, that deploys from the instance deploy directory, in the above case C:/home/jboss/server/deploy.
      This allows to have a clear separation between the system services and the user applications, because the instance deploy dir will contain only the user applications and they will be deployed only when all the system is up and running.

      Now, I?m using this kind of configuration on my pc to mimic the production machines and test application deployment on the same kind of configuration.
      I?d like to be able to use JbossIDE to publish on this kind of configuration, but even if I?m able to define and start the different instance of the servers as described above, I?ve found some drawbacks that do not allow me to use it to publish projects in the above kind of configuration.

      1- the first is that i need to alter the jndi port number in the launch configuration stop and twiddle args to match the number defined for the instance, but after a start and a stop of the server, the port number in the launch configuration is reset back to the default value of 1099.
      2- The publish is always creating the project wars in ${ jboss.home.dir}/default, while the correct publishing directory should be ${ jboss.server.home.dir} that for the above configuration is C:\home\jboss\server\ssrv10
      3- This is really minor, but the port numbers shown in descriptor XPaths properties are the ports of the ${ jboss.home.dir}/default/conf/jboss-service.xml not the real ones with which the server is running, that where changed by jboss.system:service=ServiceBindingManager during the server startup.

      Now, given that the jboss.* properties are meant exactly to allow this kind of configuration, similar to that of Tomcat, one installation multiple instances, i?m asking for the following enhancements:

      1- please, once the launch configuration is created and changed by the developer it must not be altered any longer, unless the developer is explicitly doing it (this smell like a bug? :))
      2- the publish directory must be configurable and not default to the deploy directory of the configuration chosen for the runtime
      3- I know I?m asking too much, but think how wonderful it could be if the XPaths ports values displayed were the real ones with which the server is running, taken from the mbeans ;)

      What do you think about?

      Thanks, Gabriele

        • 1. Re: JBossIDE-2.0.0.Beta2 enhancements to support complex Jbo
          rob.stryker

          Right now the entire infrastructure is set up to depend entirely on which configuration that was chosen for the runtime. The reasons are many.

          I originally tried having a runtime which was just the server home, and then let the "server" object keep track of which configuration was in use, but then when I wanted to use these runtimes for webtools-type projects, the "runtime" didnt have access to the "server", and I couldn't get a reference to the jars in a specific configuration's folder / deploy directory.

          So it became clear the runtime needed to hold all the data, including which configuration was being run at that moment. I realize you've been overriding it with command-line arguments, but it's simply not set up right now to do that.

          This is the reason for all of your listed problems. It's the reason the jndi port keeps getting reset (although that does sound fishy), it's the reason the publish directory is static, and it's probably the reason the xpaths are not showing you the values you expect. In all cases, its drawing from the runtime configuration you've chosen, which seems to be default rather than the ssrv10 you've put in via command line args.

          In all honesty, I just didn't expect people to be using the infrastructure in this way, and so I didn't plan for it.

          • 2. Re: JBossIDE-2.0.0.Beta2 enhancements to support complex Jbo
            garu

            Ok, i know it may sound complicated, but that kind of configuration, ie keeping well separated the installation from the configuration/customization part was the only way to obtain that Jboss was accepted in the production environment and i'm really sorry that with eclipse and Jboss in 2006 i'm not yet able to do what was possible with Jbuilder and Tomcat back in 2002. Having a single installation/runtime and multiple instances/configurations.

            Believe me, keeping that kind of configuration also in the pc has its advantages. Instead of spreading all the configuration changes in the various files i have all the customizations in a single place different from the installation and, for example, migrating from 4.0.4 to 4.0.5, which i did recently, costed me just the time to download and unpack the zip file.

            Unfortunately it's since webtools was born that from time to time i try to see if i'm able to obtain what i need, with no luck and i guess this is another time i'll have to throw in the trash can all the JbossIDE/webtools again and resort back to the old ant way.

            Are you really sure you cannot do anything in this direction?

            In any case be sure i appreciate what you have done up to now with your ide.

            Thanks, Gabriele

            • 3. Re: JBossIDE-2.0.0.Beta2 enhancements to support complex Jbo
              maxandersen

              Rob,

              I know alot (or even all) of this stem from the inflexibility of the server model in WTP, but what prevents us from allowing the user to select a "auto-detect" configuration which would contact the server for details ?! or am i missing something?

              To Garu,

              Isn't this all possible if you just create a runtime/server pair per setup you want to run with a different configuration selected for each ?

              /max

              • 4. Re: JBossIDE-2.0.0.Beta2 enhancements to support complex Jbo
                garu

                Hi Max,
                yes it's possible to do what you say, but this is exactly what i want to avoid and it wouldn't solve my needs.
                First i'd need to replicate the default or all structure, services and libs, as many times as the number of diferent instances.
                Second i don't want to alter installation files, otherwise each time i have to install a new release i'll have to go hunting for changes in the services xml files to replicate them in the new installation. Instead i want to keep my changes only in one place, in the bindings xml file.
                This means that ide would still see the 1099 port default and it would continue to reset it.
                Third, the publish process would still build the project ear/war in the runtime deploy directory.
                Instead i want it to publish in the instance deploy directory which is seen by a different url deployer than the one that sees the runtime deploy directory.

                You see, it's not that easy and as Rob said it may involve deep changes.
                But IMO having JbossIDE able to keep up with the flexibility that JbossAS has in building enterprise configurations would be a great plus.

                Regards, Gabriele

                • 5. Re: JBossIDE-2.0.0.Beta2 enhancements to support complex Jbo
                  maxandersen

                  ...and you say this was implemented in JBuilder ?

                  • 6. Re: JBossIDE-2.0.0.Beta2 enhancements to support complex Jbo
                    garu

                    Well, not really this :)
                    At that time i was working with Tomcat and i remember i was able to do something similar with with Jbuilder, it was a mix of Jbuilder support and ant but i could publish and debug on different tomcat instances with a single runtime.

                    At that time it was not even possible to start Jboss with an instance directory different from the installation runtime.
                    The basic support was already there but it was not correctly working. I remember i submitted a couple of patches to correct startup behaviour and allow jboss.* properties reference within jboss-service.xml to allow this kind of configurations.
                    Since then i switched to Eclipse and i've always used this kind of conf both in production and development environments.

                    Regards, Gabriele