4:21 a.m.
I discovered that the CLI 'module' command has been in need of a discussion for
awhile. There are some issues with the command, and lingering enhancement requests, that
can't be cleared up unless a future is clearly established. Since I can't seem to
find any existing discussion on the subject, I wanted to throw it out here.
Issues:
* The main issue is that the current command simply doesn't interact with the server
to do anything. It relies on file system access and creates or removes module directories
and resources on it's own. The server can then reload and find them. Simple, but
effective.
* Another issue is that the command is disabled for domain mode. Interestingly, since the
command can be used in a disconnected state, it can still be used to manipulate domain
modules assuming the servers module path remains the default at
'JBOSS_HOME/modules'. A module can be added or removed while the CLI is
disconnected, then it can connect and reload the servers to complete the add or remove.
Refactoring Thoughts:
To bring it in-line with most other commands, and allow it to be expanded, the process
should probably be happening server-side rather than CLI-side. I'm envisioning
something akin to the deploy functionality. For the time being refactoring a simple
add/remove, but later expanding it to be far more functional. However I haven't had
the chance yet to look into how, or if, the server maintains or manipulates the modules
and paths anywhere or if the value is simply passed into the jboss-modules system. I
don't believe there's a clear API for the modules system at the moment, so this
puts me somewhat in the dark as to whether what I'm thinking about is even possible.
Of course, everything is possible. With enough work.
Concerns:
* My main concern with needing a connection is that the current functionality would
suffer. Right now the module command, being independent from the server, is enabled while
the CLI is disconnected. I think that functionality is somewhat valuable since a
standalone server reload does not actually remove a module. Once added and the server
reloaded, a module is active until a full shutdown and restart. From what I understand
it's much easier to add classes to a JVM than remove them, so this is expected. If not
fixed a standalone server would have to be started, then the module removed, then shutdown
and restarted. While not excessive, it is a little annoying.
* Also, as pointed out earlier, the command can currently be used on domain servers if
certain criteria are met. If a connection is required the command would become completely
unusable for domain servers unless the functionality is expanded during the refactoring.
** Note: The first concern doesn't seem to apply to domain servers, since the servers
can be completely restarted from the host controller.
Thoughts and input are encouraged. Whether on the technical aspects of a refactor or
simply using the command.
Joe Wertz