Am 02.09.2012 20:11, schrieb Mark Thomas:
> 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.
Just did, see here:
http://java.net/jira/browse/SERVLET_SPEC-45
>
>>>> 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
My problem with the EAR is, that the web artifacts within, would all
have different contexts. I would like to be able to implement artifacts
that are not only connected to a host web artifact, but can also be
"used" as standalone artifacts. Just imagine that you have something
like a "common.war" which contains templates etc. which are used by
"blog.war" and "news.war". In other words "blog.war" and "news.war" have
a dependency on "common.war".
Now there exists a "host.war" which composes all three war files
together and sets e.g. links to pages of them into a menu. Now you have
a scenario, where you can use "common.war" together with "blog.war"
standalone, but also use all of the "modules" within "host.war". This is
not about multiple web applications, but splitting up a big web
application into little module, preferrably war files since they can
then also be used standalone(important for modular testing). In JSF you
can for example add jar-files into WEB-INF/lib that contain JSF
resources/components which can be used within JSF. That is somehow a
"light" approach which is bound to JSF.
Why not allow some kind of sub modules in war files that can be used
just as if those were packaged within the war file? IMO war files that
are somehow connected(e.g. via manifest entry) to a "host" war file is a
way to solve this kind of modularity problem. What do you think?
Regards,
Christian