| |For those of us who haven't been there before, what do these comments mean? |Was there a decision made to do away with the Class-Path entries that some |of us just missed out on? And if so, did we decide to just have a single |classloader for an entire J2EE app? Or am I just not |comprehending what you |are saying? | |It seems to me, based on Gabor's note, that the easiest and most spec |compliant thing would be to make putting ejb-jars into the app classpath an |option, presumably based on the Class-Path entry. If you don't like the |Class-Path entry we could use some other mechanism I guess. | This is what the current deployer looks for, very by the book, very cumbersome, very unelegant and in our case very broken. |Or we could just toss the whole thing and have a single ClassLoader that |loads everything in sight regardless of what the user wants. This seems |like a poor idea to me but not the end of the world. I still don't see how |we can get around using the Class-Path entry to find shared jars - |unless we |want to search the ear file and include everything with an name ending in |.jar :( no, the single CL is even a worse idea, we do have a new structure of CL in Dr Jung's and my proposal. They do away with the "archaic" delegation that is not suited. I will get 2.1 beta this week so we can work on the deployer then. Regards marc Well there are ways to load "on demand |
