The other day in #jbosstesting IRC a few of us discussed SHRINKDESC-21 and adding a "read-only" mode to SWD.

Ralf has implemented a POC (which is now in upstream/SHRINKDESC-21), and I'd made some notes regarding its design on the pull request[1]. We'd then determined that there should be a relationship between the read-only and mutable views such that the user could switch from one to the other; this isn't a security feature perse to prevent unauthorized state changes, but more a way of guarding against accidental ones and clearly denoting which calls are safe for read-only operations.

Not really; because at this point WebAppDescriptor is no longer a parent of WebAppMutableDescriptor, so you can't directly cast from one to the next. The only way to do that is to show the user the common superclass, the base, with all the generic parameters in place.

Again, don't blame me. This is how Java handles generics. Even though WebAppDescriptor and WebAppMutableDescriptor are equivalent at runtime because the compiler drops the generics when generating bytecode, the hierarchy is broken and hence not castable.

Cool API design from a real java generic expert. I would probably spend weeks for this in a try and error manner:-)

To be honest, I have to work with this approach before I can truly say "yes, I got it". Shall I try to enhance the POC? I am sure there are some questions coming up, which we don't see without coding or generating.

Tell ya what; I'll continue on this POC and implement the "toImmutable()" and "toMutable()" approach outlined, then we can all see it in action. Of course the real question is if we feel this satisfies the feature request to provide read-only views (not from a security standpoint, but from a simple-to-understand view that signals which metadata is meant to be read and what's to be mutated). Will ping back.

Great. Just proceed as you propose. I just saw a little difference to the existing descrptors. I generated the root element directly into the descriptor. I had some troubles with the generics at that time...

There is a little thing I have to mention. All xsd elements (nodes) except the root element cannot have a reference to the descriptor. This must be generic since xsd elements are reusable by other descriptors. So, for example the ModuleType in the application.xsd is:

By the way, do you have a problem calling the mutable types ModuleTypeMutable instead of ModuleMutableType? It is better to extend a given name instead of putting a pattern in the middle of the given name.

I want to make a suggestion outside of this discussion context that came to mind while looking at the example.

The method getOrCreateFilter() seems clunky to me. A method name that I think works better is createUnlessExists(), where it's understood that create() returns a reference to the node. Get and create are very different operations, but an understood return value on a create method provides a reader without mixing operation intents in the method name.

I recommend making one name change. If the intent of the mutable/immutable operations is to provide a different view (that has a different access level), I think that "as" is a more appropriate prefix for the method name.

asMutable instead of toMutable

The reasoning here is that "to" implies a conversion, but the object state is not being changed here. What is being changed is the client's access to that state, which is what "as" suggests to me.