[wildfly-dev] CLI 'module add/remove' Command Discussion

[Brian Stansberry]

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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat