6 Replies Latest reply on Nov 25, 2008 4:16 AM by Emanuel Muckenhuber

    Hotdeployment is still broken

    Adrian Brock Master

      If I change a jsp page it shouldn't be redeploying the war file!

        • 2. Re: Hotdeployment is still broken
          Adrian Brock Master

          Ok, Sacha/Scott asked me to look at this
          (well actually he asked me to look at something else but this is close enough ;-)

          This hasn't moved on much since I first raised this issue:
          http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4064180#4064180
          and as Charles points out on the JIRA, the touch of deployment descriptors is broken
          again
          http://www.jboss.com/index.html?module=bb&op=viewtopic&t=145508

          The basic issue here is that we now have three scanning mechanisms
          (one of which isn't currently getting used).

          There is

          1) the HDScanner which has some sane rules and a decent abstraction
          but it is only used during the initial scan at bootstrap time
          2) a MetaDataAwareProfile that knows where deployment descriptors live
          3) a SerializableDeploymentRepository that assumes incorrectly that a profile
          is made of local directories

          Neither (2) or (3) are aware of the "sane" rules that the initial HDScanner
          used when determining what is a deployment.

          The SerializableDeploymentRepository also doesn't seem to understand
          that there should be any number of (sub-)profiles and that they could be activated
          "on the fly":
          http://www.jboss.com/index.html?module=bb&op=viewtopic&t=136492
          It doesn't seem to understand (sub-)profiles at all?

          There is an APPLICATION_TRANSIENT phase in there but it doesn't look
          to be complete or have a notion of whether a (sub-)profile is currently active
          when looking for modifications.

          • 3. Re: Hotdeployment is still broken
            Adrian Brock Master

            There are actually two quick fixes which solve the
            initial problems described above.

            1) Copy some of the "sanity" rules into the SerializableDeploymentRepository
            such as not recursing into directories that have a dot in the name (although even
            for that rule there is a FIXME in the HDScanner :-).

            This doesn't solve the fundamental issue which is that profile implementations
            should be definable per sub-profile. The repository should not be
            interfering with the initial definition or assuming anything about it, let alone being that definition.

            2) Include the MetaDataAware handling in the SerializableDeploymentRepository
            so we know when deployment descriptors (anything in the metadata-locations)
            get modified.

            The other problems are much too fundamental for quick fixes. ;-)

            • 4. Re: Hotdeployment is still broken
              Adrian Brock Master

               

              "adrian@jboss.org" wrote:

              1) the HDScanner which has some sane rules and a decent abstraction
              but it is only used during the initial scan at bootstrap time


              When you are not using the repository.

              • 5. Re: Hotdeployment is still broken
                Scott Stark Master

                 

                "adrian@jboss.org" wrote:

                2) Include the MetaDataAware handling in the SerializableDeploymentRepository
                so we know when deployment descriptors (anything in the metadata-locations)
                get modified.

                We need this to know when admin edits are out of date anyway, so let's focus on that fix.


                • 6. Re: Hotdeployment is still broken
                  Emanuel Muckenhuber Master

                   

                  "adrian@jboss.org" wrote:

                  2) Include the MetaDataAware handling in the SerializableDeploymentRepository
                  so we know when deployment descriptors (anything in the metadata-locations) get modified.


                  Yes - i was creating JBAS-6148 because of that :)

                  Furthermore:
                   <!-- A filter for excluding files from the scanner -->
                   <bean name="DeploymentFilter" class="org.jboss.virtual.plugins.vfs.helpers.ExtensibleFilter">
                   <!-- Files starting with theses strings are ignored -->
                   <property name="prefixes">#,%,\,,.,_$</property>
                   <!-- Files ending with theses strings are ignored -->
                   <property name="suffixes">#,$,%,~,\,v,.BAK,.bak,.old,.orig,.tmp,.rej,.sh</property>
                   <!-- Files matching with theses strings are ignored -->
                   <property name="matches">.make.state,.nse_depinfo,CVS,CVS.admin,RCS,RCSLOG,SCCS,TAGS,core,tags</property>
                   </bean>
                  


                  Is not taken into account at all in the repository profile and the basic profile it's also not considered for ModifiedDeployments (JBAS-6147)