|1. Serialised. intra-vm calls should cause a suitable |WARNING - not an ERROR.
if we look for speed and you make a mistake on the CL, this is deep I want your face to be splattered in blood as you stared at the raw engine. Integration is the key, I give you 2 options, both will work with the RH cl. |I think, after a good 5 mins deep consideration, that |the App server should provide the following classes to |a SANDBOXED application. | |1. J2SE x.x |2. J2EE y.y |3. Common local infrastructure | |Since the app is sandboxed, it should be able to |override these with it's own version. Please explain this. |I guess if you want your own version of JAXP then you |should probably have to include your own |implementation as well. Jung's implementation of my ideas supported this. Ie we look for local classes first and then go to the repository to get the rest if not found this enables you to override with local implementations. I am against this, I would use it explicitely with a scope (I.e. if you define a scope then you have the same behaviour, it will take the one define locally) but if you don't then this is going to be a nightmare of classcasts like we have today if you are not careful with the packaging, ie it kills what we are trying to do. So we can support this but I think it should be slightly different than the way it is implemented now (could be wrong on memory here). |Should the app-server not try, even in this situation, |to optimise intra-container calls ? sure, of course, done! marcf | |Jules | | --- Rickard Öberg <[EMAIL PROTECTED]> wrote: > |Julian Gosnell wrote: |> |> > 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? :-) |> |> On the one hand, having straight-forward |> classloading makes it easy to |> develop a web-app. On the other hand, having |> sandboxed classloading |> makes the web-app more self-contained and portable, |> since they don't |> rely on the surrounding server to provide any of its |> classes. |> |> > If you do that with Jetty in stand-alone, |> compliant |> > mode - you will simply find you are using the JAXP |> > that Jetty loaded to parse it's own XML |> configuration |> > files. |> |> |> Yes, the straight-forward mode. |> |> |> > If you do it with Jetty in embedded, non-compliant |> > mode - you will find isAssignableFrom() fails. |> |> |> Yup, the more complex and portable case. |> |> /Rickard |> |> -- |> Rickard Öberg |> | |__________________________________________________ |Do You Yahoo!? |Everything you'll ever need on one web page from News and Sport to |Email and Music Charts |http://uk.my.yahoo.com | |------------------------ Yahoo! Groups Sponsor ---------------------~--> |Universal Inkjet Refill Kit $29.95 |Refill any ink cartridge for less! |Includes black and color ink. |http://us.click.yahoo.com/1_Y1qC/MkNDAA/ySSFAA/CefplB/TM |---------------------------------------------------------------------~-> | |For the latest information about Jetty, please see http://jetty.mortbay. | |Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ | | _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
