accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: [DISCUSS] Not Deploying Monitor as a WAR
Date Tue, 31 Mar 2015 22:57:44 GMT
On Mon, Mar 30, 2015 at 5:10 PM, Mike Drob <mdrob@apache.org> 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

Mime
View raw message