On Mon, Mar 30, 2015 at 5:10 PM, Mike Drob <[email protected]> wrote: > Hey Accumulators, > > I was thinking about this, and couldn't find the appropriate JIRA, so I'm > brining it up on the mailing list. >
https://issues.apache.org/jira/browse/ACCUMULO-1325 > I think I'm opposed to packaging the monitor as a WAR and trusting users to > figure out how to make that work. Packaging as a war doesn't obligate users to figure out how to make it work. It *may* make it easier to deploy in different environments. It also *may* make our standalone server implementation simpler (Jetty can launch/serve a war). > - We'll have to develop community knowledge on several technologies to > provide support. Some users will prefer Tomcat, some Jetty, others JBoss, > etc... When a problem is reported, it will be hard to tell if it's a > container issue or an Accumulo issue, all adding to our support burden. I'd expect any user using a war version instead of the standalone script-launched Jetty version to have some basic knowledge about their container in order to provide useful information in debugging. Stack traces also help. Monitor issues tend to be more presentation-based, anyway. The monitory shouldn't be doing much complex work that would differ between containers. While I appreciate the fact that this could become a concern... I think it's a bit early to anticipate this at this point. > - We'll have to seriously rework a bunch of tests to set up containers for > the Monitor. Not sure I agree with this one. Wars are intended to be pretty portable. As long as we're not doing container-specific stuff, code tested in one container should work in others. In any case, I would not be a favor of introducing a lot of container-specific code to do this. If it turned out that was needed, I'd probably abandon the idea (if it were mean doing the work). > - I don't think this would gain us anything in terms of security, and > might make things like KRB trickier to use. > Well, it could buy us some security, if we relied on container-provided security mechanisms which were standardized between containers. I don't think that's the case today (we're relying on Jetty's provided security mechanisms for TLS, if enabled, but that's pretty much it; in my experience, I've found these things to be notoriously divergent between containers, and pretty frustrating, so that may end up being a show-stopper anyway). The reasons for doing this would not be security-related reasons. They would be "development ease", "modularity", and "deployment convenience" reasons. We're more likely to improve our security (significantly, I would imagine) by using standard tools, like Jersey / Jackson, and other libraries to generate the content on our pages, rather than writing directly to HTTP headers / body in raw servlets. But, that's a separate issue from WAR packaging. > This isn't a complete list, but I would be interested in having this > conversation. I don't know how much work has already been done on the topic > (Christopher?). > Thanks for bringing up the conversation and expressing your concerns. I'm glad to have the conversation. I think if we ended up doing this, it would be after some experimentation to determine what roadblocks might occur. And, if we did do it, I would not want to remove the simplicity of the current standalone JAR-based artifact, rather use the WAR to support other use-cases while consolidating the actual code. Leaving the current launchable mechanism in place (rather than flat-out replace it with a WAR) I think addresses most of your concerns. To my knowledge, no work has been done since I created the JIRA issue. As stated in JIRA, I've played around with that kind of packaging (in the past), and it worked out well enough for me. But, that's not necessarily a guarantee that it will meet our needs. > > Thanks, > Mike
