I wanted to be able to access the domain api that is currently served up by the domain-api-http services on localhost:9990/domain-api via the jbossweb connectors (localhost:8080/domain-api by default), so I created a org.jboss.as.web.domain.{DomainApiContextService,DomainApiServlet} pair that does this. I only have the GET access working at the moment, but wanted feedback on how to proceed as the DomainApiServlet has to duplicate a lot of the domain-api-http org.jboss.as.domain.http.server.DomainApiHandler because of the servlet api vs org.jboss.com.sun.net.httpserver differences. It is relatively easy to refactor the DomainApiHandler to isolate the differences so that the bulk of the code can be used by the DomainApiServlet, but before doing that I wanted some feedback on the changes so far: https://github.com/starksm64/jboss-as/commit/03cc9156e05358f3e1a6d36c4df7... Should this be in the web module or factored out into a new module that depends on domain-api-http and web? _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

What is the intended use of this servlet? One of the ongoing problems that JBoss AS has had as long as there has been a management component made available over the JBoss Web / Tomcat connector is that end users will expose that over the internet unsecured.

I'll defer to Darran on the security aspects of this; i.e. how to ensure that this webapp integrates with management layer's security configuration.

If we do this, it shouldn't be enabled by default for the reasons Darran mentioned. But the patch doesn't seem to have it on by default. We'll need to disable this capability for a server running in domain mode, as a domain mode server is not meant to expose a directly-accessible-to-the-end-user management interface. The host controller exposes that. On 6/8/11 2:56 PM, Scott Stark wrote: > I wanted to be able to access the domain api that is currently served up > by the domain-api-http services on localhost:9990/domain-api via the > jbossweb connectors (localhost:8080/domain-api by default), so I created > a org.jboss.as.web.domain.{DomainApiContextService,DomainApiServlet} > pair that does this. I only have the GET access working at the moment, > but wanted feedback on how to proceed as the DomainApiServlet has to > duplicate a lot of the domain-api-http > org.jboss.as.domain.http.server.DomainApiHandler because of the servlet > api vs org.jboss.com.sun.net.httpserver differences. It is relatively > easy to refactor the DomainApiHandler to isolate the differences so that > the bulk of the code can be used by the DomainApiServlet, but before > doing that I wanted some feedback on the changes so far: > > https://github.com/starksm64/jboss-as/commit/03cc9156e05358f3e1a6d36c4df7... > > Should this be in the web module or factored out into a new module that > depends on domain-api-http and web? > > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

This is not a pull request, just a review request.

I'll be testing stuff out on my own branch as part of the openshift testing before creating anything to merge. The DomainServletApi and /domain-api context are not added by default in this set of changes for review. So, I ran into at first choosing the wrong service name for the source of the ModelController being org.jboss.as.domain.controller.DomainController.SERVICE_NAME vs org.jboss.as.server.Services.JBOSS_SERVER_CONTROLLER. Is it correct that the former is only available when running in domain mode and the lack of a Services.JBOSS_SERVER_CONTROLLER indicates that standalone mode is not active? On 6/8/11 1:39 PM, Brian Stansberry wrote: > > I'll defer to Darran on the security aspects of this; i.e. how to ensure > that this webapp integrates with management layer's security configuration. > > If we do this, it shouldn't be enabled by default for the reasons Darran > mentioned. But the patch doesn't seem to have it on by default. > > We'll need to disable this capability for a server running in domain > mode, as a domain mode server is not meant to expose a > directly-accessible-to-the-end-user management interface. The host > controller exposes that. > _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

I'm thinking this work probably best fits in a new subsystem that builds on both the domain-http-api and depends on jbossweb as the http server rather than org.jboss.com.sun.net.httpserver.HttpServer. Now I would think if used, this is a new interface in the management-interfaces: <management-interfaces> <!-- <native-interface interface="default" port="9999"/> <http-interface interface="default" port="9990"/> --> <jbossweb-interface interface="..." context="domain-api" ... /> </management-interfaces>

and there would have to be some extension api to expand the management-interfaces domain configuration. > Do you have any idea of the timescale for this? Is this something you > are looking to have in 7.0.0 or 7.1.0? > Probably 7.1 as I'll just use a branch for any immediate term released I need to do for openshift.

No, org.jboss.as.domain.controller.DomainController.SERVICE_NAME is for a service that only runs in the DC process. A server process will have org.jboss.as.server.Services.JBOSS_SERVER_CONTROLLER whether it's in domain mode or standalone mode. A quick solution is inject the o.j.a.server.ServerEnvironment (under name org.jboss.as.server.ServerEnvironmentService.SERVICE_NAME) and in your start() method check the getLaunchType() property. It will return one of: public static enum LaunchType { DOMAIN, STANADALONE, EMBEDDED } If DOMAIN, don't install the servlet. (I'll fix the typo in the enum!) Better would be to catch this on the domain controller when it processes the profile. With some stuff I'm doing on a branch that will be easy enough to do; if you assign a JIRA to me to do that, I can add it when I merge your stuff into the branch. Or tell you how to do it if my branch is merged before you're ready.

... That's correct; the host.xml parser should just barf if that element were present. Having a service that's part of the core AS depend on a subsystem makes me queasy. Mostly because I sense a slippery slope. But there's no reason it shouldn't work.