| Item |
Type |
Comment |
Response |
| 1 |
Clarification |
2.2, #1 - what does it mean that "domain.xml is no more a dependable interface"? |
|
| 2 |
Clarification |
2.2, #4 - why no multi-mode? is it hard? |
|
| 3 |
Clarification |
2.2, #5 - why no JMX connector? |
|
| 4 |
Editorial |
There's two section 2.2's |
|
| 5 |
Clarification |
2.2 (second one) - I don't understand the last sentence |
|
| 6 |
Clarification |
4.1.1, 411-1 - can we defer most or all of this work until we have a JSR-303 implementation? I don't think we should be building a whole other validation infrastructure. |
|
| 7 |
Clarification |
4.1.1, 411-2 - why would you need to turn validation off? performance concerns? |
|
| 8 |
Clarification |
4.1.1, 411-3 - this is good, but can we defer this until after Prelude? |
|
| 9 |
Comment |
4.1.1, 411-4 - as we've discussed before, the ability to replace pieces of a modular app server means the utility of an overall version number is less and most things should not be using it to make decisions. in particular, we shouldn't depend on this for upgrade. |
|
| 10 |
Clarification |
4.1.1, 411-6 - I'm torn on this one. On the one hand, I like the idea of being able to have a very minimal domain.xml with no unneeded fluff. On the other hand, we've used the default elements in domain.xml as a sort of documentation of template for people who want to customize domain.xml. Rather than learning about what elements and attributes exist, and figuring out where to put them in domain.xml, they can see them already in the proper place with the current values set. Perhaps an appropriate "complete" domain.xml could be used as documentation, even though the server normally runs with a minimal domain.xml. What's the strategy here? Are you concerned about losing the documentation attributes of domain.xml? |
|
| 11 |
Clarification |
4.1.1, 411-7 - Do you have more details on how you plan to address the sub-tasks? |
|
| 12 |
Clarification |
4.1.1, 411-8 - We've gone back and forth on whether it's an advantage or a bug to have admin traffic on the same port as user requests. I'd like to understand the strategy here and why we chose which default. |
|
| 13 |
Clarification |
4.1.1, 411-9 - we discussed some of this in email. I'd like to understand in which cases users are expected to modify domain.xml by hand. Hopefully there's an obvious way for a module to cause elements to be added to domain.xml when needed. |
|
| 14 |
Clarification |
4.1.2, 412-1 - when you start with -verbose, what happens when you type CTRL-C? |
|
| 15 |
Clarification |
4.1.2, 412-1 - it's unfortunate that restart isn't supported if you don't use -verbose. what do other app servers do to handle this? |
|
| 16 |
Clarification |
4.1.2, 412-3 - this seems fine, but I'm curious... what are the use cases for setting environment variables? |
|
| 17 |
Clarification |
4.1.3, 413-2 - I don't understand the second comment |
|
| 18 |
Comment |
4.1.3, 413-3 - I think we need to keep the ant tasks for compatibility, if not for Prelude then certainly for the final release |
|
