> > The solution you presented at the time was to create an alternate scanner > > for this purpose. I don't like that since it violates the concept of > > exploded archives being treated just like their packaged counterparts. > > What? No it does not at all. It is just the same, it is just a matter of > which scanner it came from. > > .... yada-yada > > We do not want to get back into the monolithic component business again. > Design with plugablility then make use of it when you need new functionality. > If required refactor the existing components to better seperate the > plugability... but don't go making simple components complicated when you > could have easily created a replacment or peer to gain the same result.
Multiple scanners make it difficult at best to define deployment ordering. URLDeploymentScanner is already written (by you, I might add) to handle two forms of deployment: Directory scanning and direct URL deployment. I am trying very hard NOT to complicate this issue, but we do need a solution for exploded archives. The simplest at this point is to preserve the functionality of URLDeploymentScanner, and that means make it understand exploded archives. You call it a hack, and I agree. However, we already have a hacked system that will hopefully be fixed shortly. Forcing me down the awkward path of well architect code that must function within a design that has outlived its usefulness is not the right answer. Let me hack this for now, and spend my time on a better designed rewrite. -Larry _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
