Is there a Plan to Consilidate Dependency Resolution of Module/Deployment Dependencies and OSGi dependencies?

[steffenwollscheid]

Hi,

it seems to me that, when a stating a dependency to a module/deployment, using either the Manifest-Header "Dependencies" or the deployment-structure.xml there is no means to use a version range to depend on.

This is in contrast to the OSGi subsystem.

Therefore if an OSGi bundle A dependes on a package from bundle B version [1.1.0,1.2) (to prepare for future patches/hotfixes before the next minor release) and bundle B version 1.1.0 is hotfixed to version 1.1.1 then bundle A will still be satisfied and working, without the need to replace it also.

If enterprise deployment C on the other hand also depends on bundle B it must depend on version 1.1.0 fix - because the version of the installed bundle B will end up in the slot part of the ModuleIdentifier, and finally in the name of the jboss.module.spec.service.* and must therefore be explicitly stated in the Dependencies of the EE deployment (after the colon).

Is there any intention to consolidate the behaviour of the enterprise dependency stating and resolution with that of the OSGi subsystem, to address hotfix scenarios as mentioned above?

(Preferably by allowing module/deplyoment dependencies to be given with range expressions in the "Dependencies" manifest header and jboss-deployment-structure.xml.)

Unless this is consilidated, large scale applications employing OSGi and EE will have to be designed around this duality of dependency resolution.

A workaround might be done by introducing arbitrary empty host bundles with fixed version numbers to be referenced from EE deployments and adding the current implementation bundles as fragments to those.(Separating the interfaces only in base bundles referenced by EE and OSGi deployments might not be a viable option in all scenarios). But this would be truly ugly.

What do you recommend?

Thanks!

Steffen

[thomas.diesler]

This restriction has gone - the version only needs to be specified if there is ambiguity.

Could you please try the latest master for the upcomming 7.2.0.Alpha1

[steffenwollscheid]

Thank you for the answer! Just tested it successfully with 7.2.0.Alpha1-SNAPSHOT.

One follow-up question:

From what i just tested, when moving to 7.2.0 form 7.1.1 all Dependencies-Headers referring to OSGi Bundles will have to be changed from "deployment".<bundle-symbolic-name>.<bunde-version> to "deployment".<file-name>."jar".

Did I get this wrong, or is this an intended incompatibility?

Perhaps it would be possible to register jboss.module.spec.service.deployment.<bundle-symbolic-name>.<bundle-version>  as an alias to jboss.module.spec.deployment.<file-name>.jar, and adapt the jboss-modules/ModuleLoader accordingly to accept a module-spec found when looking for deployment.<bundle-symbolic-name>.<bundle-version> even though it gives deployment.<file-name>.jar as its ModuleIdentifier -- maybe after checking the Manifest.

Best Regards

Steffen

[thomas.diesler]

Yes, I thought of that and originally had an alias. Then I decided against it because the general vision is that bundle deployments should be treated like any other deployment wherever possible.

But I agree for backward compatibility we could have the alias for a little longer. Please monitor/vote on https://issues.jboss.org/browse/AS7-5593

[thomas.diesler]

Actually I changed my mind and going from 7.1.x to 7.2.x would be a good momemt in time to get rid of the outdated way to reference a bundle module

[sascha.vogt]

Hi Thomas,

I'm a bit puzzled about the long term vision of JBoss and OSGi / JEE interdependencies. Any pointers (e.g. links zu Jiras, Wiki-pages, etc.) where I can read more would be greatly appreciated.

For now, what I understand:

• With OSGi it is often the case to have multiple versions of the same bundle deployed. That's one of the big reasons to use OSGi in the first place.
• For the JBoss module deployment I understand, that each bundle needs to have a different file name if it should live along another version of the same bundle. This means something along the lines of having the bundle version in the file name. If I have a look at for example Eclipse bundles, they usually also have the build qualifier in the file name to be able to easily distinguish different builds.
• What OSGi provides to cope with the above statements are the bundle's symbolic and the bundle's version. To further allow easier collaboration between bundles one can use optional dependencies and version ranges (version ranges obviously being the important ones).

While that's all pretty straight-forward when doing OSGi only I at the moment struggle to see how that fits with the JBoss modules and JEE parts of JBoss. Especially the following use cases:

• Calling EJBs from an OSGi bundle
• Using OSGi bundles as libraries in EJBs

If the file name is used to reference bundles from EJBs one (a) has to strip the version from the file name, which means the referenced bundle can only exist once in the container or (b) I have to change each EJB which depends on that specific bundle each time I release a new (even micro) version of the bundle. While option a) makes OSGi in a hybrid scenario rather useless, option b) is not really usable in a real world scenario. The concept of the symbolic name and version ranges is missing to me right now. Is there anything I'm missing completely?

Greetings

-Sascha-

[thomas.diesler]

In AS7 every deployment needs to have a unique name - the file name is only the default

[standalone@localhost:9999 /] deploy --help
SYNOPSIS

    deploy (file_path [--script=script_name] [--name=deployment_name] [--runtime-name=deployment_runtime_name]
                      [--force | --disabled] [--unmanaged])
           | --name=deployment_name
           [--server-groups=group_name (,group_name)* | --all-server-groups]
           [--headers={operation_header (;operation_header)*}]

DESCRIPTION

    Deploys the application designated by the file_path or enables an already existing
    but disabled in the repository deployment designated by the name argument.
    If executed w/o arguments, will list all the existing deployments.

ARGUMENTS

 file_path           - the path to the application to deploy. Required in case the deployment
                       doesn't exist in the repository.
                       The path can be either absolute or relative to the current directory.

 --name              - the unique name of the deployment. If the file path argument is specified
                       the name argument is optional with the file name been the default value.
                       If the file path argument isn't specified then the command is supposed to
                       enable an already existing but disabled deployment, and in this case the
                       name argument is required.

 --runtime-name      - optional, the runtime name for the deployment.

 --force             - if the deployment with the specified name already exists, by default,
                       deploy will be aborted and the corresponding message will printed.
                       Switch --force (or -f) will force the replacement of the existing deployment
                       with the one specified in the command arguments.

 --disabled          - indicates that the deployment has to be added to the repository disabled.
 
 --unmanaged         - if this argument is not specified, the deployment content will be
                       copied (i.e. uploaded) to the server's deployment repository
                       before it is deployed.
                       If the argument is present, the deployment content will remain
                       at and be deployed directly from its original location specified
                       with the file_path.
                       NOTE: exploded deployments are supported only as unmanaged.

 --server-groups     - comma separated list of server group names the deploy command should apply to.
                       Either server-groups or all-server-groups is required in the domain mode.
                       This argument is not applicable in the standalone mode.

 --all-server-groups - indicates that deploy should apply to all the available server groups.
                       Either server-groups or all-server-groups is required in domain mode.
                       This argument is not applicable in the standalone mode.

 -l                  - in case none of the required arguments is specified the command will
                       print all of the existing deployments in the repository. The presence of the -l switch
                       will make the existing deployments printed one deployment per line, instead of
                       in columns (the default).

 --headers           - a list of operation headers separated by a semicolon. For the list of supported
                       headers, please, refer to the domain management documentation or use tab-completion.

 --script            - optional, can appear only if the file_path points a cli archive.
                       The value is the name of the script contained in a cli archive to execute.
                       If not specified, defaults to 'deploy.scr'. 
                       A cli archive is a zip archive containing script(s) as well as artifacts or applications 
                       to deploy. To be recognized as a cli archive, the extension of the archive file should be '.cli'.
                       The deploy command will execute the script given by the --script argument. 
                       All paths in the scripts are relative to the root directory in the cli archive. 
                       The script is executed as a batch.

So uniqueness for a deployment is already well defined. The ModuleIdentifier associated with a deployment, which also needs to be unique, derives from the deployment name. If I add an alias to the ModuleIdentifier I would need to worry about that this is unique as well, which I can easily avoid by not providing an alias.

Generally, the difference between an OSGi deployment and a non-OSGi deployment should only be limitted to the way the wiring is constructed.

* In case on non-OSGi it is hard coded in the Dependencies clause or in some DeploymentUnitProcessor (DUP) that processes the deployment. IMHO this approach vialoates some of the fundamental principles of modularity, but that is not too bad if its use is limmited to internals only and does not leak into user deployments. i.e. hard coded dependencies in the manifest are bad

* In case of OSGi deployments, there is an external authority that is tasked to provide a consistent wiring (i.e. the OSGi Resolver). Once the wiring, and the associated Module/ClassLoader is available the DUPs should work just the same and it should be transparent that they are dealing with an OSGi deployment.

So going forward you would just stick OSGi metadata (i.e. Import-Package) in your manifest and such make the EJB3 deployment an OSGi Bundle and forget about hard coded dependencies. In that way your complex EE application can be made modular. My favorite example is that of a large webapp where features are provided by individual bundles that can have independent lifecycle. They can be developed by disconnected teams will well defined capability/requirement contracts between them. Additionally, by virtue of being an OSGi Bundle, features can be started,stoped,updated,etc and the webapp would react dynamically. Another benefit is that by starting/stopping the top-level webapp bundle you can make the http endpoint available/unavailable.

In short, if modularity is a concern to you or you like to uses the benefits of OSGi dynamic services - make it a bundle.

[sascha.vogt]

Hi Thomas,

Thanks for the pointer, that the file name is only the default. I wasn't aware of that.

Regarding the use of OSGi deployments for EE components: Sounds good, but (correct me if I'm wrong) this is only available since 7.2 right? Up to know we're using 7.1.x but we'll definitely have a look at 7.2 and maybe using that options. Thanks a lot for your detailed answer.

Greetings

-Sascha-

[thomas.diesler]

Yes, that is only available in the current master. Having said that, it would help greatly if folks like you get their hands on that and provide feedback before it makes it into a release. This is esspecially important with an AS7 release cycle of > 6months.