Overall, I'm concerned about the security aspects of this console, and how it will fit
in with a customers overall security implementation. Considering customers like
Mastercard, which have network devices for encryption and key management, etc., they will
want everything to be able to work through that infrastructure, and not have to manage
security differently for our console.
This type of thing could become a very real impediment to adoption of EAP 6 down the
road.
Let's make sure we include Anil and his folks in these security discussions, so we
don't end up with something that doesn't fit into the long term goals, and
potentially becomes a show stopper for customer to adopt the next major EAP release.
Andy
----- Original Message -----
From: "Heiko Braun" <hbraun(a)redhat.com>
To: ssilvert(a)redhat.com
Cc: jboss-as7-dev(a)lists.jboss.org
Sent: Thursday, January 20, 2011 10:10:43 AM
Subject: Re: [jboss-as7-dev] Management Console JDK Server Example
On Jan 20, 2011, at 6:02 PM, ssilvert(a)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.
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?
Might look trivial, but simple bit's easily add up to a pile of work.
Ike
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev