|
6407877
|
Incorrect migration occurs while migrating
from Web Server 6.0 to 7.0 if the installed.pkg file is not found.
In Web Server 6.0 to 7.0 migration, if the installed.pkg file
is missing, Web Server incorrectly migrates the NSServlet entries
in the magnus.conf file.
|
|
6502529
|
6.1->7.0: Migration does not handle
relative path set for search-collection-dir correctly.
During instance migration, specifying a relative path for the
target path into which the search collections should be copied, results
in the search collection directory being created with respect to the config-store. When the instance is instantiated, the indexes
are created without properly migrating the search collections.
|
|
6498806
|
On Windows, Web Server Admin Console
does not appropriately warn users during migration.
Administration Server does not detect if the selected new configuration
or the service name already exists on Windows and hence does not appropriately
warn the users to select a different configuration name or suggest
a different configuration name as default.
|
|
6747123
|
The request processing behavior has
changed in Sun Java System Web Server 7.0 Update 2 release.
This change
does not manifest while using Web Server 7.0 Update 2 RPP.
A modification
in the Web Server's request processing engine to fix a significant
error in Web Server, has changed the order in which the web server
processes objects and directives in the server's obj.conf file.
This correction now guarantees that the below rules are applied while
processing a request:
-
All ppath objects that apply to a request
are evaluated
-
If there is a named object that applies to a request,
it will take precedence over any ppath objects in
cases where the two conflict. If your obj.conf file
contain ppath objects, evaluate them to
determine if your obj.conf file requires any modification.
As a consequence of the above change in the request processing behavior,
when you upgrade previous Web Server versions to the Web Server 7.0
Update 2, or later, you may have to make minor changes to the obj.conf files,
as listed below:
-
Using IF directive
In the following example, directives contained in the ppath objects
will not be invoked when an explicit JSP extension is found in the
request URI, as the ntrans-j2ee NameTrans SAF will apply
to a JSP extension and cause the object named j2ee to
be evaluated next. The WebLogic proxy service used here to forward
requests to the WebLogic server is no longer invoked, although there
are no modifications made to the obj.conf file.
As a result, the web server sends the request to it's own web container,
instead of the WebLogic proxy, resulting in failure of the request.
In the obj.conf file, default object,
add a conditional statement to the ntrans-j2ee service
with the problem URIs, as shown below:
<Object name="default">
AuthTrans fn="match-browser" browser="*MSIE*" ssl-unclean-shutdown="true"
#
#Adding <IF...> and </IF> bracketing to compensate
for change in ppath processing
#
<IF $uri !~ ".*WebApp/.*" >
NameTrans fn="ntrans-j2ee" name="j2ee"
PathCheck fn="find-index-j2ee"
ObjectType fn="type-j2ee"
Error fn="error-j2ee"
</IF>
|
....
....
<Object name="j2ee">
Service fn="service-j2ee" method="*"
</Object>
<Object ppath="*/examplesWebApp/*" >
Service fn=wl_proxy WebLogicHost=jwsse10.red.iplanet.com WebLogicPort=7001
</Object>
<Object ppath="*/ejemploWebApp/*">
Service fn=wl_proxy WebLogicHost=jwsse10.red.iplanet.com
WebLogicPort=7002
</Object>
</Object>
|
This allows the ntrans-j2ee to
be executed only when the URI's do not match.
-
Using assign-name NameTrans
In simple scenarios,
you can change ppath objects to name objects
by using assign-name in the default object.
This allows the assign-name to be executed ahead
of ntrans-j2ee.
<Object name="default">
NameTrans fn="assign-name" from="/examplesWebApp/*" name="examples_proxy"
NameTrans fn="assign-name" from="/ejemploWebApp/*" name="ejemplo_proxy"
NameTrans fn="ntrans~j2ee" name="j2ee"
....
....
</Object>
<Object name="j2ee">
Service fn="service-j2ee" method="*"
</Object>
<Object name="examples proxy" >
Service fn=wl_proxy WebLogicHost=jwsse10.red.iplanet.com WebLogicPort=7001
</Object>
<Object name="ejemplo proxy">
Service fn=wl_proxy WebLogicHost=jwsse10.red.iplanet.com WebLogicPort=7002
</Object>
|
-
Disabling
Turning off Java Web container support on web server will ensure
that the JSPs will be handled by WebLogic proxy function. However,
this is only suggested when you do not intend to host Java content
in the proxying tier.
|
