12:50 p.m.
FYI, Flavia Rainone was looking into this general topic, so you should
coordinate with her.
On 4/24/15 4:21 AM, Edward Wertz wrote:
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.
I'm fine with that limitation. I don't think the CLI should be in the
business of making local changes not mediated by the server.
The offline CLI stuff in WF 9 Beta1 may help with this, as the CLI can
delegate to server-side logic without needing to spin up a separate process.
* 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.
The big issue with this in domain mode is that domain mode is all about
maintaining consistency across the domain. That includes things like
sending deployment content to new hosts that join the domain long after
the first addition of the deployment. When we have CLI commands for
things, I expect that basic behavior pattern will be upheld. To have
equivalent behavior with modules that we have with deployments, that
means storing data in the domain-wide persistent configuration, a la
what we do with deployments. It's that data that drives the ability to
provide content to newly joining hosts.
If we don't store that kind of data in the domain-wide config, this
becomes more of a what I call a "provisioning" feature. Provisioning was
very much out of scope for AS 7's management layer. We can of course
consider changing the scope, but IMHO we need to have a very broad
discussion before doing that. (So thanks for this thread.) We shouldn't
do it via feature creep, which is what the current 'module' command was.
Joe Wertz
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat