Bug 1189170

There is missing severity - setting high. Feel free to change it.

Hi Tomas,

I did some testing and noticed that when I modify attribute or invoke operation in CLI in messaging subsystem then no message like "xyz is deprecated" is logged. Is this expected to behave this way? From my point of view it's OK as it would be annoying to log such a thing for anything. I just want to confirm this is expected behaviour. 

I've noticed that when I deploy MDB then there is no WARN message in server.log that module org.hornetq.ra or org.hornetq is deprecated. Should be HornetQ resource adapter deprecated as well?

In case when I add "Dependencies: org.hornetq" to MANIFEST.MF to MDB then I can see warning:
14:50:54,934 WARN  [org.jboss.as.dependency.deprecated] (MSC service thread 1-1) JBAS015980: Deployment "deployment.mdb.jar" is using a deprecated module ("org.hornetq:main") which may be removed in future versions without notice. 

Thanks,
Mirek

Hi Miroslav,

This is expected behavior, we didn't want to be too invasive with warning people about deprecation with every single operation / attribute that it is deprecated.
As this would than mean there would be tons of warnings.
In model itself if you do /subsystem=messaging:read-resource-description(...)
you should see also extra entry:

deprecated {
   since: <version>
   reason: text description why
}

As minimum requirement we decided that at least root resource should have this defined. But for most subsystem we went ahead and added this information for all resources. Attributes & operation that are part of this resources have this omitted as it would only be overhead given that if resources is deprecated everything on it is deprecated.

In other cases where whole subsystem is not deprecated you could find this metadata also on single attribute or operation as well.

About the dependencies we warn similarly as to with jboss.api = private where we warn users that they are referencing private modules, we now warn about deprecation as well. Just keep in mind if module is already private we didn't also deprecate it as private is more than just deprecated.

This warnings are displayed only when user deployment is referencing deprecated modules, if this comes from system modules this warnings are not present as in case of MDBs, whole subsystem is already deprecated why annoy people with more.

Thanks Tomas for feedback. I don't see any issue. Setting as verified.

Tomaz's answer is good. To fill it out a bit more:

There is some background on what is and is not possible in http://post-office.corp.redhat.com/archives/eap-pm-list/2015-February/msg00025.html (linked to from EAP6-345). This explains why you only see the module warning when explicitly including it in your MANIFEST.MF.

HornetQ RA is already 'private', which is more restrictive than 'deprecated'. 'deprecated' is for modules which are currently public, which might be removed in the future. Users should never use 'private' modules.

We definitely will not want to log a message when deploying an MDB. People using the Java EE spec 'cleanly' should not see any warnings at all. Although HornetQ will be gone in 7, people will still be able to deploy MDBs using the new implementation of messaging.

The log message output by writing attributes is legacy stuff which has been around for a few releases, so we can't remove that at this stage. The current preference would be for something non-logging, as we have now implemented with resource adds and so on.

John Doyle <jdoyle> updated the status of jira EAP6-345 to Closed