Julian Gosnell wrote:
2. Non-compliant - only requests for system classes
are passed upwards.
FWIW, Tomcat4 does the same thing, which means that you have to bundle
in jaxp.jar in your webapp, or you're going to get strange class-cast
exceptions and class-not-found exceptions. The solution
Your just putting the onus on the Application
programmer to work around shortcomings in the Server -
I think.
Perhaps someone will make a pronouncement on HOW
JBoss/Jetty SHOULD behave here. Then we can figure out
how to achieve this behaviour.
--- Rickard Öberg [EMAIL PROTECTED] wrote:
So,
Are you saying that we should simply support both -
but not a third strategy which somehow supports
sandboxing AND optimised intra-container calls ?
1. Serialised. intra-vm calls should cause a suitable
WARNING - not an ERROR.
2. I believe that we need a third strategy.
This is not the
Julian Gosnell wrote:
Your just putting the onus on the Application
programmer to work around shortcomings in the Server -
I think.
But that is exactly the problem with the non-compliant
class loader as specified by the 2.3 servlet spec.
Because it advocates a application developer
--- Julian Gosnell [EMAIL PROTECTED] wrote:
So,
Are you saying that we should simply support both -
but not a third strategy which somehow supports
sandboxing AND optimised intra-container calls ?
1. Serialised. intra-vm calls should cause a
suitable
WARNING - not an ERROR.
2. I
Julian Gosnell wrote:
So,
Are you saying that we should simply support both -
but not a third strategy which somehow supports
sandboxing AND optimised intra-container calls ?
Well, I believe the real fix is to make the EJB-loader use the non
Java2 class-loading style as well, i.e. force
--- Rickard Öberg [EMAIL PROTECTED] wrote:
Julian Gosnell wrote:
So,
Are you saying that we should simply support both
-
but not a third strategy which somehow supports
sandboxing AND optimised intra-container calls ?
Well, I believe the real fix is to make the
EJB-loader
Julian Gosnell wrote:
What goes into 3?
Your site's e.g. Logging classes etc.. which every app
uses. You figure it's cheaper to load them once into
the apps parent CL, than many times, into every app.
Ok, good point. I believe Tomcat handles this by using a common
directory that
-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott -
Optimised intra-container calls ClassLoaders
Julian Gosnell wrote:
Your just putting the onus on the Application
programmer to work around shortcomings in the Server -
I think.
But that is exactly the problem with the non-compliant
Rickard Öberg wrote:
Julian Gosnell wrote:
Are you saying that we should simply support both -
but not a third strategy which somehow supports
sandboxing AND optimised intra-container calls ?
Well, I believe the real fix is to make the EJB-loader use the non
Java2 class-loading style as
Scott M Stark wrote:
That is correct. The packaging required to run under a 2.2 servlet container
is inconsistent with that required to run under a 2.3 container due to the
change in the web container class loader behavior. I see this with Tomcat
3.2.3
vs Tomcat 4.0. Really, the only time
21, 2001 2:58 AM
Subject: Re: [jetty-discuss] Re: [JBoss-dev]
JBoss3/Jetty4, Greg/Scott -
Optimised intra-container calls ClassLoaders
Julian Gosnell wrote:
Your just putting the onus on the Application
programmer to work around shortcomings in the
Server -
I think
-
From: Rickard Öberg [EMAIL PROTECTED]
To: Scott M Stark [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Wednesday, November 21, 2001 3:30 AM
Subject: Re: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott -
Optimised intra-container calls ClassLoaders
Scott M Stark wrote
Julian Gosnell wrote:
OK - So I will go with Jetty's non-compliant
ClassLoader strategy. Calls will only be delegated
upwards if they cannot be satisfied locally.
Please don't call it Jetty's non-compliant strategy! We are just
relunctanly following the servlet spec!-)
Trouble is, this
, 2001 3:30 AM
Subject: Re: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott -
Optimised intra-container calls ClassLoaders
Scott M Stark wrote:
That is correct. The packaging required to run under a 2.2 servlet
container
is inconsistent with that required to run under a 2.3
Greg Wilkins wrote:
What class does it fail for? Can't you remove that class/jar from
the webapplication, so that it can only be loaded from the EJB classloader?
It should be loaded by the EAR loader methinks.
--
Rickard Öberg
___
Scott M Stark wrote:
Really, what was the package structure that caused the exception? I
thought I had tested a number of variations and hadn't seen any issues
with normalized ears.
We had to include jaxp.jar and crimson.jar in our EAR to get XML parsing
to work. With only jaxp.jar you get
|I was getting nasty errors when trying to make
|optimised calls from the web to the ejb container.
|
|It seems that while JBoss is aware that both client
|and server objects exist within the same vm, it was
|upset that the call was being serialised, instead of
|just simply made natively, and
| 2. Non-compliant - only requests for system classes
| are passed upwards.
|
|
|FWIW, Tomcat4 does the same thing, which means that you have to bundle
|in jaxp.jar in your webapp, or you're going to get strange class-cast
|exceptions and class-not-found exceptions. The solution is to bundle all
|
|Your just putting the onus on the Application
|programmer to work around shortcomings in the Server -
|I think.
Like I said, dumb backwards thinking, I am in fact doubtful that Craig would
do such a thing, Rickard you sure about this?
|Perhaps someone will make a pronouncement on HOW
| Your just putting the onus on the Application
| programmer to work around shortcomings in the Server -
| I think.
|
|
|Yes, the app programmer needs to know about classloading. Bug..
|feature.. bug... feature.. which'll it be? :-)
|
100% bug
|On the one hand, having straight-forward
|I guess if you want your own implementation of JAXP,
|then you should probably have to reinclude the JAXP
|api itself
no problem use the scope.
marcf
|
|
| Should the app-server not try, even in this
| situation,
| to optimise intra-container calls ?
|
| Jules
|
| --- Rickard Öberg
|Well, I believe the real fix is to make the EJB-loader use the non
|Java2 class-loading style as well, i.e. force people to bundle in JAR's
|that the app is going to use. That is the ultimate way to get things
|portable, and to be able to allow different running apps use different
|versions of,
|If they are not optimised, RH currently throws an
|exception and the test fails. So this needs fixing.
RH is still using the old CL structure for the apps, when we default to the
scope stuff, this class of problems will go away, we will need to integrate
them with Jetty in teh 2 fashions
|Julian Gosnell wrote:
|
|What goes into 3?
|
|
| Your site's e.g. Logging classes etc.. which every app
| uses. You figure it's cheaper to load them once into
| the apps parent CL, than many times, into every app.
|
|
|Ok, good point. I believe Tomcat handles this by using a common
|directory
|Well, *all* access from the web container to EJB's (i.e. servlets too)
|need to be aware of these changes. We ran into this the other day, and
|the fix was to bundle crimson.jar into our app too (i.e. not rely on it
|being available).
|
|Now, because of all this bundling going on, the EAR
mails
marcf
|
|- Original Message -
|From: Greg Wilkins [EMAIL PROTECTED]
|To: [EMAIL PROTECTED]
|Cc: Rickard Öberg [EMAIL PROTECTED];
|[EMAIL PROTECTED]
|Sent: Wednesday, November 21, 2001 2:58 AM
|Subject: Re: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott -
|Optimised intra
| Well, I believe the real fix is to make the EJB-loader use the non
| Java2 class-loading style as well, i.e. force people to bundle in JAR's
| that the app is going to use. That is the ultimate way to get things
| portable, and to be able to allow different running apps use different
| versions
]
| JBoss3/Jetty4, Greg/Scott -
| Optimised intra-container calls ClassLoaders
|
|
| Julian Gosnell wrote:
|
| Your just putting the onus on the Application
| programmer to work around shortcomings in the
| Server -
| I think.
|
|
| But that is exactly the problem with the
| non
]
| Sent: Wednesday, November 21, 2001 3:30 AM
| Subject: Re: [jetty-discuss] Re: [JBoss-dev] JBoss3/Jetty4, Greg/Scott -
| Optimised intra-container calls ClassLoaders
|
|
| Scott M Stark wrote:
|
| That is correct. The packaging required to run under a 2.2 servlet
| container
OK,
I'll risk one more posting...
Marc,
You seem to understand where I am coming from !
When will this new CL stuff come in ?
Jetty's WAR CL will be a child of the one passed us by
the J2EEDeployer in
Thread.currentThread().getContextClassLoader().
What should it's behaviour be ?
1.
|the reason it remains is that most implementations have such
|a huge problem getting the class loader scopes to work at
|all, that making it configurable is just impossible.
|(believe it or not!)
look we are going to put it out with Jetty and when you see other vendors
starting to support the
|When will this new CL stuff come in ?
all the code is out, what is missing is SCL/SL integration that david and i
are talking about.
|Jetty's WAR CL will be a child of the one passed us by
|the J2EEDeployer in
|Thread.currentThread().getContextClassLoader().
|
|What should it's behaviour be ?
On 2001.11.21 13:16:11 -0500 marc fleury wrote:
Sanity,
thanks professor seems you are on shore with me for once :)
| Regardless, I'm going to work on the deployment layer to clean it up
| and add support unarchived ears.
|
|I the likely case you get to this before I do, my goals for
So just to clarify all this...
RH is the next release of JBoss (Rabbit Hole?) and it will include a
classloader that supports scopes.
I gather that scopes are a way to control class loading that is not
directly related to the parent hierarchy of classloaders (inverted or
otherwise).
|RH is the next release of JBoss (Rabbit Hole?) and it will include a
|classloader that supports scopes.
yes,
the scopes are already there
|I gather that scopes are a way to control class loading that is not
|directly related to the parent hierarchy of classloaders (inverted or
|otherwise).
36 matches
Mail list logo
