Would Spring Boot be a possibility?
On Mon, Mar 30, 2015 at 6:14 PM, Josh Elser <[email protected]> wrote: > btw, top-level issue: https://issues.apache.org/jira/browse/ACCUMULO-3034 > > Mike Drob wrote: >> >> On Mon, Mar 30, 2015 at 4:42 PM, Josh Elser<[email protected]> wrote: >> >>> I don't recall the exact ticket either (despite owning it at least at one >>> point), but the intent wasn't to force users to only deploy the monitor >>> in >>> some server as a WAR, but enable users who wish to do that to be able to. >>> >>> The default would still be launching a standalone webserver as is done >>> presently via Jetty. >>> >>> +1 > > > Cool, glad that isn't an issue. Hopefully I can swing back around to this > and finish it eventually. It was much nicer than before: > > https://github.com/joshelser/accumulo/tree/jersey-monitor > >> >>> Some more inline: >>> >>> Mike Drob 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. >>>> >>>> I think I'm opposed to packaging the monitor as a WAR and trusting users >>>> to >>>> figure out how to make that work. >>>> - 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. >>>> >>> Relying on Servlet3 should alleviate most of the concerns for >>> implementation specifics. I think wiring up a security layer to the >>> monitor >>> is very specific. Given that we don't have anything presently, I think >>> that's a minor concern (and would need to be addressed if/when we get >>> there). >>> >> >> Well, there could also be stuff like "in Tomcat the default number of >> threads is too low for log forwarding to work, you should increase it." In >> Jetty, setting Y needs to be changed. We increase our configuration >> surface >> area by however many containers there are. > > > Absolutely. Things should work out of the box on most app servers; hopefully > we can rely on the community to share results as people try it out > themselves. Hard to guess at where things might break. > >>> - We'll have to seriously rework a bunch of tests to set up >>> containers >>>> >>>> for >>>> the Monitor. >>>> >>> What monitor tests? We have next to none that test much anything >>> meaningful. I don't see testing burden as a reason to not make a change >>> that (is intended) to also make things more testable. >>> >> >> I was thinking of the servlet tests, maybe those don't need to change. It >> would be important to make sure that things like the shell servlet still >> work on Jetty/Tomcat/etc... That would be a pretty embarrassing bug to >> ship >> out, and I can easily see it getting missed. > > > We presently have 4 test classes in monitor/ and none of them test that the > servlets themselves. I know we have an IT or two which pull the index page > of the monitor, but they're not actually verifying anything other than an > HTTP/200 IIRC. > > IMO, we have no monitor tests right now. It's extremely likely to be broken, > gets broken silently often > (https://issues.apache.org/jira/browse/ACCUMULO-3691 is a great recent > example), and only get noticed via devs looking at the monitor on their own. > >>> - I don't think this would gain us anything in terms of security, and >>>> >>>> might make things like KRB trickier to use. >>>> >>> I'm not sure if the authentication Filter classes fall into any defined >>> specification, but enabling SPNEGO is already a todo. Running on a >>> Kerberos-enabled cluster doesn't require SPENGO to be enabled as we are >>> already banking on nothing (overly) sensitive being displayed in the >>> monitor (whereas HDFS has the ability to traverse the filesystem). >>> >>> Again, shell servlet means that everything is potentially displayed. > > > Sure, but that's not baked into the server presently -- the authentication > we do is internal to the "application". As long as we can provide uniform > means to deploy the application in the server with SSL, we should be fine. > Stuff like this goes into server.xml (I'm not 100% sure if that's uniform > across all servers or not -- probably in the simplest form). > > Obviously, more complicated authentication/authorization schemes will be > server-dependent. > > >> >>> 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, >>>> Mike >>>> >>>> >> >
