From glyn_normington at UK.IBM.COM Thu Sep 6 08:16:21 2007 From: glyn_normington at UK.IBM.COM (Glyn Normington) Date: Thu, 06 Sep 2007 16:16:21 +0100 Subject: Fw: JSR 291 interoperation status Message-ID: Hi Stanley Please could you provide an update on your work on interoperation between JSR 277 and JSR 291? If the work is still in progress, how's it coming along and roughly when might there be a strawman proposal to review? Thanks, Glyn ----- Forwarded by glyn_normington at uk.ibm.com on 06/09/07 04:12 PM ----- glyn_normington at uk.ibm.com wrote on 21/06/2007 09:59:02 AM: > > Hi Stanley > > Thanks for the status. Please could you indicate roughly when the > strawman will be ready for initial review by this EG? Hopefully > early feedback from the Expert Group would be a help... > > Glyn > > "Stanley M. Ho" wrote on 20/06/2007 11:43:14 PM: > > > Hi Glyn, > > > > That strawman is in progress. As you mentioned, it has significant > > challenges, so it takes more time to produce compared to other > > strawmans. Please stay tuned. ;-) > > > > - Stanley > > > > > > Glyn Normington wrote: > > > Please could you give us an update on your work on interoperation with > > > JSR 291 and some idea of when a strawman is likely to be available for > > > initial review by the JSR 277 Expert Group? > > > > > > Like I said when we spoke at JavaOne, the approach you are planning on > > > taking *might* work, but it has significant challenges, so I'd like to > > > hear how it's coming along. > > > > > > Thanks, > > > > > > Glyn > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jsr277-eg-observer/attachments/20070906/7d57a7d1/attachment.html From bryan.atsatt at oracle.com Thu Sep 6 12:13:47 2007 From: bryan.atsatt at oracle.com (Bryan Atsatt) Date: Thu, 06 Sep 2007 12:13:47 -0700 Subject: Fw: JSR 291 interoperation status In-Reply-To: References: Message-ID: <46E0516B.5040304@oracle.com> I was just about to send a very similar message :^). Glyn Normington wrote: > > Hi Stanley > > Please could you provide an update on your work on interoperation > between JSR 277 and JSR 291? > > If the work is still in progress, how's it coming along and roughly > when might there be a strawman proposal to review? > > Thanks, > > Glyn > ----- Forwarded by glyn_normington at uk.ibm.com on 06/09/07 04:12 PM ----- > > glyn_normington at uk.ibm.com wrote on 21/06/2007 09:59:02 AM: > > > > > Hi Stanley > > > > Thanks for the status. Please could you indicate roughly when the > > strawman will be ready for initial review by this EG? Hopefully > > early feedback from the Expert Group would be a help... > > > > Glyn > > > > "Stanley M. Ho" wrote on 20/06/2007 11:43:14 PM: > > > > > Hi Glyn, > > > > > > That strawman is in progress. As you mentioned, it has significant > > > challenges, so it takes more time to produce compared to other > > > strawmans. Please stay tuned. ;-) > > > > > > - Stanley > > > > > > > > > Glyn Normington wrote: > > > > Please could you give us an update on your work on > interoperation with > > > > JSR 291 and some idea of when a strawman is likely to be > available for > > > > initial review by the JSR 277 Expert Group? > > > > > > > > Like I said when we spoke at JavaOne, the approach you are > planning on > > > > taking *might* work, but it has significant challenges, so I'd > like to > > > > hear how it's coming along. > > > > > > > > Thanks, > > > > > > > > Glyn > > > > > > > > > > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with > > number 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire > PO6 3AU > > > > > > > > > > > > ------------------------------------------------------------------------ > > / > / > > /Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU/ > > > > > > From Stanley.Ho at sun.com Thu Sep 6 20:57:38 2007 From: Stanley.Ho at sun.com (Stanley M. Ho) Date: Thu, 06 Sep 2007 20:57:38 -0700 Subject: Fw: JSR 291 interoperation status In-Reply-To: References: Message-ID: <46E0CC32.5090906@sun.com> Hi Glyn, The work is in progress, and there are ongoing prototypings to figure out how it should work and to also validate the overall approach. I will send out the strawman proposal for the EG to review and discuss when it is ready. Interoperability is definitely something that I would like to address before this JSR goes public review. - Stanley Glyn Normington wrote: > > Hi Stanley > > Please could you provide an update on your work on interoperation > between JSR 277 and JSR 291? > > If the work is still in progress, how's it coming along and roughly when > might there be a strawman proposal to review? > > Thanks, > > Glyn From Stanley.Ho at sun.com Thu Sep 6 21:08:11 2007 From: Stanley.Ho at sun.com (Stanley M. Ho) Date: Thu, 06 Sep 2007 21:08:11 -0700 Subject: Welcome new SAP rep to the JSR 277 EG! Message-ID: <46E0CEAB.2000100@sun.com> Hi JSR 277 experts, I would like to welcome Pavel Genevski to our EG! Pavel will replace Georgi Danov as the official SAP representative for JSR 277. Pavel, welcome abroad! - Stanley From andyp at bea.com Fri Sep 7 01:19:36 2007 From: andyp at bea.com (Andy Piper) Date: Fri, 07 Sep 2007 09:19:36 +0100 Subject: Fw: JSR 291 interoperation status In-Reply-To: <46E0CC32.5090906@sun.com> References: <46E0CC32.5090906@sun.com> Message-ID: <6.2.5.6.2.20070907091921.02d05698@bea.com> At 04:57 07/09/2007, Stanley M. Ho wrote: >Interoperability is definitely something that I would like to >address before this JSR goes public review. I think its essential andy Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. From bryan.atsatt at oracle.com Mon Sep 17 19:56:02 2007 From: bryan.atsatt at oracle.com (Bryan Atsatt) Date: Mon, 17 Sep 2007 19:56:02 -0700 Subject: Serialization... Message-ID: <46EF3E42.7040000@oracle.com> The OSGi RFP 83 [1][2] contains serialization requirements that may also be relevant to this JSR. For example, perhaps we should consider some implementation of ObjectOutputStream.annotateClass() that writes something like an import declaration, and an implementation of ObjectInputStream.resolveClass() that uses the information to locate the correct class. Thoughts? // Bryan [1] EG Wiki: http://gee.cs.oswego.edu:8086/download/attachments/257/rfp-0083-Classloading-and-Marshalling-1.pdf [2] Public (requires registration): http://www.paremus.com/downloads/downloads_engineering.html From bryan.atsatt at ORACLE.COM Mon Sep 17 19:55:40 2007 From: bryan.atsatt at ORACLE.COM (Bryan Atsatt) Date: Mon, 17 Sep 2007 19:55:40 -0700 Subject: Thread context class loader... Message-ID: <46EF3E2C.7090609@oracle.com> The OSGi RFP 83 [1][2] contains Thread context class loader requirements that are clearly relevant to this JSR. Based on a great deal of painful experience with the use/misuse of the thread context class loader, I believe that 277 must address this issue to be successful :^). I suspect that Thread.get/setContextClassLoader() will need to be updated to use a policy based implementation. At Oracle, in our EE system, we have no choice but to constantly switch the TCL as threads are assigned to execute code from one of the many possible concurrent applications. We tried various schemes for this, with the most obvious being a special delegating loader assigned as the TCL. But, due to JVM class caching, delegating loaders must have the same lifecycle as those they delegate to, and this is tricky when your threads are re-used for many different applications, each of which has it's own lifecycle. Our current solution overrides both the Thread get/setContextClassLoader() methods, and uses internal server state to determine which actual application loader to return. The state is reset each time a request processing thread is returned to the pool (Executor.afterExecute()) since application code often changes the TCL (without the reset the thread pins the loader). In an EE world, this approach works quite well since there is a natural context for class resolution: the application. This large-grained context is easily represented via a TCL, and that loader is then unconstrained as to its visibility to other loaders. There is a clear context switch opportunity as threads are assigned to execute application code or returned to the pool. In a purely module/bundle based environment there is also a natural context: the module/bundle loader. But this is too fine-grained since its expressed dependencies frequently won't (and shouldn't statically) include SPI implementation classes specified by name. And there is no switching boundary--each module/bundle loader must control it's own fate. Clearly, one answer is to introduce some form of context which enables the administrator/developer to broaden the search scope beyond the module's natural dependencies. The Equinox "buddy" policy approach is a good start, but probably needs some refinement/extension and new APIs. For example, Thread get/setContextClassLoader() methods could delegate to a policy object: interface ContextClassLoader { public ClassLoader get(); public ClassLoader set(ClassLoader loader); } (or even a type that reexports the public methods of ClassLoader to enable the policy to search across multiple loaders). But we need to be very careful about the number and kind of policies we support to minimize complexity in what is already an extremely complex environment. Oracle's class loader framework has elaborate diagnostic machinery built-in, which is called upon constantly to help solve problems--there seems to be infinite ways to mis-configure a large system of classes. And we *still* run across frameworks that don't even use the TCL and so don't work properly in a multi-loader env. Thoughts? The RFP also deals with serialization; I'll start another thread on that. // Bryan [1] EG Wiki: http://gee.cs.oswego.edu:8086/download/attachments/257/rfp-0083-Classloading-and-Marshalling-1.pdf [2] Public (requires registration): http://www.paremus.com/downloads/downloads_engineering.html From andyp at bea.com Tue Sep 18 02:43:54 2007 From: andyp at bea.com (Andy Piper) Date: Tue, 18 Sep 2007 10:43:54 +0100 Subject: Thread context class loader... In-Reply-To: <46EF3E2C.7090609@oracle.com> References: <46EF3E2C.7090609@oracle.com> Message-ID: <6.2.5.6.2.20070918103951.02c8a2f8@bea.com> At 03:55 18/09/2007, Bryan Atsatt wrote: >Thoughts? Given our experience with OSGi I agree that this needs addressing. We have found, though, that the notion of a "thread of execution" is somewhat more amorphous in a non-JEE environment. In using Spring-OSGI we have found we often have to force the client classloader to be a delegate of the target bundle's, but there are issues with trying to actually make this switch happen. I'm wondering whether we actually need some VM-level support to make this work well. andy Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. From andyp at bea.com Tue Sep 18 02:44:11 2007 From: andyp at bea.com (Andy Piper) Date: Tue, 18 Sep 2007 10:44:11 +0100 Subject: Serialization... In-Reply-To: <46EF3E42.7040000@oracle.com> References: <46EF3E42.7040000@oracle.com> Message-ID: <6.2.5.6.2.20070918104406.02daf538@bea.com> +1 andy At 03:56 18/09/2007, Bryan Atsatt wrote: >The OSGi RFP 83 [1][2] contains serialization requirements that may also >be relevant to this JSR. > >For example, perhaps we should consider some implementation of >ObjectOutputStream.annotateClass() that writes something like an import >declaration, and an implementation of ObjectInputStream.resolveClass() >that uses the information to locate the correct class. > >Thoughts? > >// Bryan > >[1] EG Wiki: >http://gee.cs.oswego.edu:8086/download/attachments/257/rfp-0083-Classloading-and-Marshalling-1.pdf >[2] Public (requires registration): >http://www.paremus.com/downloads/downloads_engineering.html Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. From Stanley.Ho at sun.com Tue Sep 18 08:12:45 2007 From: Stanley.Ho at sun.com (Stanley M. Ho) Date: Tue, 18 Sep 2007 08:12:45 -0700 Subject: Thread context class loader... In-Reply-To: <46EF3E2C.7090609@oracle.com> References: <46EF3E2C.7090609@oracle.com> Message-ID: <46EFEAED.7090302@sun.com> Hi Bryan, Just let you know. I am currently out of office, and I will follow up this and the serialization discussions later this week. - Stanley Bryan Atsatt wrote: > The OSGi RFP 83 [1][2] contains Thread context class loader requirements > that are clearly relevant to this JSR. Based on a great deal of painful > experience with the use/misuse of the thread context class loader, I > believe that 277 must address this issue to be successful :^). > > I suspect that Thread.get/setContextClassLoader() will need to be > updated to use a policy based implementation. > > At Oracle, in our EE system, we have no choice but to constantly switch > the TCL as threads are assigned to execute code from one of the many > possible concurrent applications. We tried various schemes for this, > with the most obvious being a special delegating loader assigned as the > TCL. But, due to JVM class caching, delegating loaders must have the > same lifecycle as those they delegate to, and this is tricky when your > threads are re-used for many different applications, each of which has > it's own lifecycle. > > Our current solution overrides both the Thread > get/setContextClassLoader() methods, and uses internal server state to > determine which actual application loader to return. The state is reset > each time a request processing thread is returned to the pool > (Executor.afterExecute()) since application code often changes the TCL > (without the reset the thread pins the loader). > > In an EE world, this approach works quite well since there is a natural > context for class resolution: the application. This large-grained > context is easily represented via a TCL, and that loader is then > unconstrained as to its visibility to other loaders. There is a clear > context switch opportunity as threads are assigned to execute > application code or returned to the pool. > > In a purely module/bundle based environment there is also a natural > context: the module/bundle loader. But this is too fine-grained since > its expressed dependencies frequently won't (and shouldn't statically) > include SPI implementation classes specified by name. And there is no > switching boundary--each module/bundle loader must control it's own fate. > > Clearly, one answer is to introduce some form of context which enables > the administrator/developer to broaden the search scope beyond the > module's natural dependencies. The Equinox "buddy" policy approach is a > good start, but probably needs some refinement/extension and new APIs. > For example, Thread get/setContextClassLoader() methods could delegate > to a policy object: > > interface ContextClassLoader { > public ClassLoader get(); > public ClassLoader set(ClassLoader loader); > } > > (or even a type that reexports the public methods of ClassLoader to > enable the policy to search across multiple loaders). > > But we need to be very careful about the number and kind of policies we > support to minimize complexity in what is already an extremely complex > environment. Oracle's class loader framework has elaborate diagnostic > machinery built-in, which is called upon constantly to help solve > problems--there seems to be infinite ways to mis-configure a large > system of classes. And we *still* run across frameworks that don't even > use the TCL and so don't work properly in a multi-loader env. > > Thoughts? > > The RFP also deals with serialization; I'll start another thread on that. > > // Bryan > > [1] EG Wiki: > http://gee.cs.oswego.edu:8086/download/attachments/257/rfp-0083-Classloading-and-Marshalling-1.pdf > > [2] Public (requires registration): > http://www.paremus.com/downloads/downloads_engineering.html