[jboss-as7-dev] Management Console JDK Server Example

[Jason T. Greene]

On 1/20/11 11:10 AM, Heiko Braun wrote:
>
> On Jan 20, 2011, at 6:02 PM, ssilvert at redhat.com wrote:
>
>>> It's not reinventing the servlet API, it's using an alternative one
>>> that accomplishes then same thing but with minimal overhead.
>>
>
>
> Let's get back to more concrete requirements. I already suggested a discussion about security to begin with.
> If any of those identify a dependency on the servlet API, or reveal that supporting libraries
> that depend on the servlet API help us achieving our goals with less work, then we should consider a servlet runtime.
>
> If nothing of that is the case, fine, then proceed with the embedded server approach.

I totally agree here. Ultimately I'm fine if this approach doesn't pan 
out, but I think we should have a very good reason why we didn't go down 
that route.

>
> Another thing that we might consider it configuration of the HTTP endpoints.
> TLS has been mentioned. How would that work on embedded HTTP? How would you specify
> and use certificates? Would we need to write all that on our own?

It just uses JSSE (which is what all of the java web servers internally 
use). So you just create an SSLContext using a keystore/truststore as 
part of the https connection. You can also make decisions based on the 
incoming ip address, which allows you to do things like force user cert 
auth.


See the example at the bottom here here:

http://download.oracle.com/javase/6/docs/jre/api/net/httpserver/spec/com/sun/net/httpserver/package-summary.html

> Might look trivial, but simple bit's easily add up to a pile of work.

It's all about trade-offs. It's important to understand the impact of 
all options. As an example we can pick a large framework to attack a 
problem, however then we have to maintain it and all of it's 
dependencies, write integration code, configure it properly and figure 
out how to expose the elements that are relevant to the user.

-- 
Jason T. Greene
JBoss, a division of Red Hat