"Kevin.Conner(a)jboss.com" wrote : "tfennelly" wrote : 1. Add a strict
config model inside the ESB config file whereby we only allow certain configurations and
we manually map those appropriately to the web.xml going into the generated .war sub
deployment.
| This allows us to remain in control of what we support and is the preferred method.
Kev, please lets not say "it is the preferred method" just yet!!
At the moment, I don't agree with your analysis for a number of reasons. As far as I
see it, we can easily control what we merge from the user defined web.xml into the
generated web.xml, so having control is not really an issue IMO. Also, I don't agree
that we should be restricting the user unless there is a "grave" danger that
they would not be able to resolve easily. I don't see this as being one.
The down side as I see it would be that implementation of the "strict model"
becomes quite a bit more complex since a mapping process would be more complex (IMO) than
a filtering process. We have to document this new config model (the web.xml approach is
already well documented and familiar to the user). We have to maintain it going forward.
In some ways, I feel we are reinventing the wheel with this approach.
"Kevin.Conner(a)jboss.com" wrote : "tfennelly" wrote : 2. We allow the
user to specify a suplemental web.xml that gets merged into the generated web.xml. The
user would define the "extra" configs as per the web.xml schema. We could allow
them specify this inline in the esb config, or externally. We might want to restrict the
config types we allow in this e.g. you can't define any servlet/filter configs etc??
| This is likely to lead to problems unless the restrictions are so strict as to end up
with the equivalent of the first suggestion. Adding explicit support, especially under
our control, is much easier than disabling parts.
Well firstly, I wouldn't be in favor of restricting the user in this case, but even if
we do decide to do that, I think if we keep the config the same as that of the web.xml,
the maping process is considerably easier for us to implement/document and is more natural
to the user. Same points as I made above.
"Kevin.Conner(a)jboss.com" wrote : "tfennelly" wrote : The existing http
gateway also supports configuration of allowed http methods. Do we need to bring this
along?
|
| Yes, we need to retain support for the following verbs, DELETE, HEAD, GET, POST and
PUT. We also need to provide automatic support for OPTIONS so that someone can determine
what capabilities are present.
|
| Only TRACE, as currently implemented, is not required.
|
Sorry Kev... I wasn't clear in the original... what I mean't was a config to
restrict the methods allowed through a given bus. The existing HTTP Gateway has an
"allowMethods" config, whose default is basically all methods (I think). This
config option allows the default to be overridden.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238153#...
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...