On 31/08/2012 19:10, Christian Beikov wrote:
> Am 31.08.2012 18:51, schrieb Mark Thomas:
>> On 31/08/2012 17:37, Christian Beikov wrote:
>>> My main question was about whether there is a way to retrieve the https
>>> port of the EE6/Servlet Container in a standard way? If not maybe a
>>> method to convert an URL in a standard way to use https?
>>>
>>> Seems like there is no standard way for doing this kind of task. My use
>>> case would be, to allow users to choose if they want to use https or
>>> not.
>> Why would you need this? The user is free to access your site via
>> http://... or https://...
>>
>> Could you elaborate on the scenarios where this doesn't work?
> Based on the preference of a user I might redirect him to the https url.
> Since the ports of a web container are not necessarily known, it would
> be handy if something like this is added. Otherwise the ports would have
> to be configured for the target runtime. The option to configure
> confidetial access for a web resource collection in web.xml is just not
> dynamic enough IMO.
Fair enough. I can think of ways to do this within the existing spec but
they are all fairly hackish. I suggest you file a Jira.
>>> I could do that with container specific configuration at deployment
>>> time too, but that would be error-prone. Antonio Goncalves also asked
>>> for a Servlet/Web-Container API which I also would like to ask for, at
>>> least I would request an API to be able to access some information of
>>> the underlying network and management specific stuff.
>> You'll need to make a much more specific request than that for it to be
>> considered.
> The only really useful thing I can think of is an API through which the
> available ports(+ protocols) of sockets that are currently bound can be
> retrieved.
See above. Include a specific API suggestion in the Jira request.
>>> I have some more things on my wishlist which I would like you to take a
>>> look at.
>>>
>>> 1. The fact that only one session config per webapp can be configured
>>> is very limiting. In the cookie config someone could configure the
>>> path of the cookie, which is somehow useless IMO since you can only
>>> use one session config. I think it would be nice to return the
>>> session based on the current servlet path when calling
>>> HttpServletRequest.getSession()
>> Doesn't that defeat the whole point of a session? Separate sessions for
>> different paths suggests (rather strongly to me) that you actually have
>> separate web applications.
> The problem is, that when webapps are packaged in in different WAR
> files, they will have different context paths, configuration has to be
> done multiple times etc. Of course some of the problems could be handled
> by the build.
>
> My use case is, that I want to "package" a backend webapp together with
> a frontend webapp into a single WAR, which would currently break my app,
> since the backend should have a different session configuration than the
> frontend.
> Maybe I am just thinking wrong, but I think that this is somehow a
> limitation.
>
> The main problem is in my opinion, that you can not say something like
> "I have one WAR file X which is the host webapp for Y and Z". It could
> be solved by allowing a WAR file to contain other WAR files for example
> in WEB-INF/lib. The sub WAR files would then be "hosted" by the parent
> WAR file.
>
> It is just an idea. Since modularization becomes more and more
> important, I thought of having to package everything into one WAR file
> is somehow bad.
Multiple WARs == EAR. Sounds like you need a full J2EE container rather
than a Servlet container.
Mark