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

[ssilvert at redhat.com]

I don't want to reinvent the Servlet API either.

I also don't understand the true benefit of running the console  
somewhere other than the DC.  Why have the extra network hop for every  
DC request?  Just call the API directly instead of messing with the  
extra complexity of remoting.


Quoting Heiko Braun <hbraun at redhat.com>:

>
> Please see my comments inline.
>
> On Jan 20, 2011, at 2:55 AM, Jason T. Greene wrote:
>
>> Our management console architecture could follow a similar approach. We
>> would have both the REST/JSON Domain API and console collected in the
>> same DC JVM. The console would then just be static content
>> (javascript/html) that issues the proper JSON requests via HttpRequest.
>>
>
> I agree that this looks like a desirable goal. However we have to   
> stay pragmatic,
> especially with regard to timeline/goals. While leveraging the embedded HTTPD
> is definitely lightweight, it also forces us to start developing on   
> a very low level.
> Especially with regard to
>
> a) supporting libraries
> b) runtime service
> c) deployment options
>
> For instance the lack of a) would mean we don't benefit from   
> libraries that may speed up development
> and reduce maintenance. Things like a REST framework or simply the   
> Servlet API come to my mind.
> It basically means, we need to implement everything that might   
> otherwise be provided by a feature complete library.
> (i.e. REST content negotiation)
>
> Missing runtime service (b) that may result in more work are things   
> like integration with a security subsystem
> and configuration. While a the Servlet API provides clear means to   
> integrate with JAAS for instance, we would need to specify and   
> implement that on our own.
>
> c) simply means we constraint ourselves and users a single deployment option.
> In Neuchatel we discussed the deliverable as  a web application   
> (war) that relies in the remoting protocol internally
> and the flexibility it would have in terms of running the web-UI   
> anywhere in your system.
>
> I think it's still desirable to aim for a low footprint   
> implementation with few dependencies,
> but in order to stay productive we need to be pragmatic with regard   
> to common API, existing services and maintenance.
>
> An alternative solution would be TJWS. It's low footprint (<100kb)   
> web server, that optionally supports the Servlet API.
> It does have more dependencies then the embedded httpd, but would at  
>  least allow for a),  provide common services (b),
> and works on simple web application archives (c).
>
>> It's also possible to do GWT-RPC this way, but that would essentially be
>> adding an extra layer, which is likely not needed. In both cases we
>> would be shifting state to client, which saves resources.
>
> AFAIKT is wouldn't be possible to run GWT RPC this way. GWT RPC   
> relies on the servlet API.
> It's internal use of policy files and means to secure the RPC   
> communication make it very difficult to use outside
> this context. For the sake of this discussion, I would say if we   
> want to use GWT-RPC, then we have we need a servlet engine. Anything  
>  else introduces an extra amount of work, with very little benefit.
>
>
>
>
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>