* SAR support
Also possible (assuming a sar is considered as a jar repository implementation).
Excellent. A SAR is a JAR that includes other JARs for the libraries and blocks, as well as the assembly and environment files.
Keep in mind that there is an issue here in that jars inside jars cannot be included in classic classloaders. Instead you have to either (a) write a new classloader implementation - like they did for Tomcat, or (b) restrict the usage of the sar to a file based environment in which you unpack the sar aand refernce to unpackaged sub-jars as direct files - but in doing so, potentially cause problems for web-apps.
We also need to think about sar as a functional description versus sar as a speciofication. My impression is that the notion of packaging a deployment unit is the subject of interest. So I'm looking at this largely in tems of replicating functionality, not necessarily format.
The current solution in Phoenix is that SARs are your whole Server Application. The SAR file is unpacked into an "apps" directory with a subdirectory for each application. The "app.home" context entry is mapped to that subdirectory for the particular SAR. From that point, regular classloader magic can still be used.
My exit criteria is a complete avalon containerment framework.
Nice goal, but hardly quantifiable. Anything we can write some
JUnit tests against?
Releases should not be made on the grounds of unit tests - instead - does a release serve sufficient value to justify a release. That a decision you take at the time of promposing a release.
Right, my point being what is the quantifiable result that lets us know when the release is final? With the mission statement above, we would never be able to release because our definition of a complete containment framework is constantly evolving.
So what is the minimal acceptable set of features you want?
We could do that .. ;-)
But we arn't under contract. As people with experience jump in and do things, so the code base will evolve. I'm not too interested on trying to set release preconditions unless someone wants to give me a healthy contract to back it up. In reality - there will be things we will want to do - for example, I've been thinking about how to autogenerate a block.xml from an assembly.xml, and a Merlin config.xml targets file from a Phoenix configuration.xml. From what I can see its all feasible. Am I going to commit to doing it - no. Will it happen - probably. Is it a release precondition ... not for me.
None of these things are a release condition, they are quatifiable goals for the release. We can always cut out the goal if there is a general lack of interest in achieving the goal.
As long as we have something to build on, while including our legacy container users, all the better..
Yep - absolutely agree.
Great to hear it.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
