Bugs item #575307, was opened at 2002-06-29 12:57
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=575307group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: T. Subramanian (t_subbu)
Assigned
Bugs item #573877, was opened at 2002-06-25 18:40
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=573877group_id=22866
Category: CatalinaBundle
Group: v3.0 Rabbit Hole
Status: Pending
Resolution: Remind
Priority: 5
Submitted By: Peter Kelley (yellekau)
|determine of the call is local or remote, and the Invocation is not
|always available.
part of the effort for JBoss 4.0 is exactly that. Get rid of the silly
little typed interfaces in the system, typed interfaces in abstract
middleware systems are silly, type is good for business applications
Hello,
A new property, java.system.class.loader, can be used under 1.4 to
determine which should be the system classloader: the standard java CL or a
customized CL. As we move forward 1.4, it means that setting the UCL as the
value of this property would allow us to simply the code regarding
I don't see why it would as the system class loader is not used
for anything. This will not obviate the need for setContextClassLoader
for in many instances this is simply setting a CL to use for identifying
the unique ENC, which class loader to start loading resources from, etc.
Only that it
well, JARs that use class.forName internaly for example would work correctly
then, classes loaded by our bootstrap code (in import statement, etc.) would
be manageable internally by our UCL and so on. I don't see the need for an
intermediate classloader that we don't own if we can remove it.
SRV.6.2.1
Only one instance per filter declaration in the deployment descriptor is
instantiated per JVM of the container. ...
When the container receives an incoming request, it takes the first filter
instance in the list and calls its doFilter method, passing in the
Request/Response and a
Number of tests run: 668
Successful tests: 668
Errors:0
Failures: 0
[time of test: 29 June 2002 15:13 GMT]
[java.version: 1.3.1]
[java.vendor: Apple Computer, Inc.]
From the servlet spec
SRV.9.8 Replacing a Web Application
A server should be able to replace an application with a new version without
restarting the container. When an application is replaced, the container
should provide a robust method for preserving session data within that
application.
