24 messages in net.java.dev.glassfish.adminRe: Comments on grizzly config one pager| From | Sent On | Attachments |
|---|---|---|
| Justin Lee | Jan 23, 2009 8:16 am | |
| Justin Lee | Jan 23, 2009 8:17 am | |
| Oleksiy Stashok | Jan 23, 2009 8:45 am | |
| Lloyd Chambers | Jan 27, 2009 12:56 pm | |
| Justin Lee | Jan 28, 2009 7:41 am | |
| Lloyd Chambers | Jan 29, 2009 10:58 am | |
| Justin Lee | Jan 29, 2009 1:01 pm | |
| Justin Lee | Jan 30, 2009 12:09 pm | |
| Lloyd Chambers | Jan 30, 2009 3:32 pm | |
| Lloyd Chambers | Jan 30, 2009 3:40 pm | |
| Kedar Mhaswade | Jan 30, 2009 3:46 pm | |
| June...@Sun.COM | Jan 30, 2009 3:51 pm | |
| Kedar Mhaswade | Jan 30, 2009 3:54 pm | |
| Lloyd Chambers | Jan 30, 2009 3:55 pm | |
| Kedar Mhaswade | Jan 30, 2009 4:40 pm | |
| Justin Lee | Jan 30, 2009 5:04 pm | |
| Jerome Dochez | Feb 2, 2009 9:20 am | |
| Kedar Mhaswade | Feb 2, 2009 10:53 am | |
| Jerome Dochez | Feb 2, 2009 11:22 am | |
| Kedar Mhaswade | Feb 2, 2009 2:15 pm | |
| Tim Quinn | Feb 2, 2009 3:05 pm | |
| Kedar Mhaswade | Feb 2, 2009 3:17 pm | |
| Jerome Dochez | Feb 3, 2009 12:50 pm | |
| Kedar Mhaswade | Feb 3, 2009 1:19 pm |
| Subject: | Re: Comments on grizzly config one pager | |
|---|---|---|
| From: | Kedar Mhaswade (Keda...@Sun.COM) | |
| Date: | Feb 3, 2009 1:19:29 pm | |
| List: | net.java.dev.glassfish.admin | |
Jerome Dochez wrote:
On Feb 2, 2009, at 2:15 PM, Kedar Mhaswade wrote:
Jerome Dochez wrote:
I would like to see the DTD for overall domain.xml validation more than field validation which as you mention will be preferably handled by the beans validation framework.
Is that (Bean Validation) happening in time for us for JavaOne? yes. I am not so sure. The current framework we have for field validation works well, IMO. We can enhance it a bit and that buys us some "time". For now, there are several @Configured interfaces that do not even do basic field validation, which is rather unpleasant.
no I think we just should delegate to bean validation, even if it limits what we can do for v3 final. I think we have enough to do than throw away code.
I will experiment with Bean Validation and get back. http://musingsofaprogrammingaddict.blogspot.com/2009/01/getting-started-with-jsr-303-beans.html
-Kedar
For a schema validation kind of requirement, yes, I agree, DTD will come in handy.
right now, the errors that we generate when fed with an incorrect domain.xml can be cryptic to the user, a xsd or dtd validation would ensure domain.xml structural validity in a more predictable manner. I don't think we *have* to do it, but I can see value.
Let me see if I can plan for it.
-Kedar
jerome On Feb 2, 2009, at 10:53 AM, Kedar Mhaswade wrote:
I agree. It's possible.
But now that we have resorted to alternate ways of doing things like validation (e.g. using data-type annotation field on attributes), we have less and less motivation to reinstate a DTD for such purposes. Unless there is a tremendous advantage of reinstating a DTD, I wouldn't vote for it. My basic idea is for documentation purpose and that's why doing it at compile time would suffice. Of course, generating DTD at runtime is attractive.
-Kedar
Jerome Dochez wrote:
Even if modules are not loaded, you can still get an exhaustive list of all @configured interfaces (costly operation as you end up starting all related modules) as long as modules are installed (meaning residing in the modules directory for instance). So I don't think it's more difficult to generate this at runtime than at compile time, although you might be missing access to the javadoc's for documenting the DTD itself. generating at runtime is interesting as it would indeed allow us to validate the domain.xml once again... probably not a mode by default considering the startup cost it would incur but very interesting for the more elaborated distributions. Jerome On Jan 30, 2009, at 4:40 PM, Kedar Mhaswade wrote:
Lloyd,
Yeah. As you can see, this can't give you an idea of modules/interfaces that are not loaded and as such it is of not much value from a documentation perspective. And yes, it is because server's configuration and runtime both are dynamic in nature.
-Kedar
Lloyd Chambers wrote:
Kedar, As I haven't looked into it, you might be right. I thought there might be a way to traverse all module, find all @Configured interfaces, build a graph (tree), then emit a DTD. In concept it seems easy enough, but of course the details might prove otherwise. Lloyd On Jan 30, 2009, at 3:46 PM, Kedar Mhaswade wrote:
Generating a DTD at runtime is hard problem to solve. It will be nice if we can at least get a DTD from config elements which are known at compile time.
-Kedar
Lloyd Chambers wrote:
Justin, Generating a DTD would be terrific, it's something on "the list". Ideally it would be built at runtime based on the loaded modules, not compile time. Lloyd On Jan 29, 2009, at 1:01 PM, Justin Lee wrote:
There is no provision in V3 for a DTD as the source of the interfaces. Java interfaces are the source at this point, the @Configured interfaces. A DTD does not work for a pluggable system; it would have infinite variation, never a fixed thing.
I'm actually in the process of making sure the DTD(s) and the interfaces are in sync and then I'll probably just remove the DTDs for good measure and work from the interfaces. I'm debating writing an hk2/maven mojo to generate a DTD/XSD for basic validation (largely for my own benefit).
---------------------------------------------------------------------
To unsubscribe, e-mail: admi...@glassfish.dev.java.net For additional commands, e-mail: admi...@glassfish.dev.java.net
---------------------------------------------------------------------
To unsubscribe, e-mail: admi...@glassfish.dev.java.net For additional commands, e-mail: admi...@glassfish.dev.java.net
---------------------------------------------------------------------
To unsubscribe, e-mail: admi...@glassfish.dev.java.net For additional commands, e-mail: admi...@glassfish.dev.java.net