[JBoss JIRA] (WFLY-13832) Bug in detecting the org.apache.cxf module
by Tomas Hofman (Jira)
[ https://issues.redhat.com/browse/WFLY-13832?page=com.atlassian.jira.plugi... ]
Tomas Hofman commented on WFLY-13832:
-------------------------------------
Reproducer app: https://github.com/TomasHofman/jboss-eap-quickstarts/commit/0f1f953b4773e...
> Bug in detecting the org.apache.cxf module
> ------------------------------------------
>
> Key: WFLY-13832
> URL: https://issues.redhat.com/browse/WFLY-13832
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 20.0.1.Final
> Reporter: Tomas Hofman
> Assignee: Tomas Hofman
> Priority: Major
>
> When deploying an EAR file which has a sub deployment that uses CXF annotation classes a warning is logged that looks like this:
> WFLYWS0065: Annotation '@org.apache.cxf.interceptor.OutInterceptors' found on class 'de.comdirect.application.mt.wsexample.server.SimpleWsServiceWS'. Perhaps you forgot to add a 'org.apache.cxf' module dependency to your deployment?
> If you declare a dependency on org.apache.cxf in the sub-deployment, the warning is not logged. However, if you declare the org.apache.cxf dependency at the EAR level with export=true you still get the message even though the CXF module should be visible.
> I tracked down the class org.jboss.as.webservices.deployers.WSClassVerificationProcessor located in the org/jboss/as/webservices/main/wildfly-webservices-server-integration-7.3.0.GA-redhat-00004.jar
> In this class there is a method which logs this message, plus an additional related method:
> private void verifyApacheCXFModuleDependencyRequirement(DeploymentUnit unit) {
> if (!hasCxfModuleDependency(unit)) {
>
> CompositeIndex index = (CompositeIndex)unit.getAttachment(Attachments.COMPOSITE_ANNOTATION_INDEX);
> DotName[] dotNames = \{ DotNames.WEB_SERVICE_ANNOTATION, DotNames.WEB_SERVICE_PROVIDER_ANNOTATION };
> for (DotName dotName : dotNames) {
> for (AnnotationInstance ai : index.getAnnotations(dotName)) {
> AnnotationTarget at = ai.target();
> if (at instanceof ClassInfo) {
> ClassInfo clazz = (ClassInfo)ai.target();
> for (DotName dn : clazz.annotations().keySet()) {
> if (dn.toString().startsWith("org.apache.cxf")) {
> WSLogger.ROOT_LOGGER.missingModuleDependency(dn.toString(), clazz.name().toString(), "org.apache.cxf");
> }
> }
> }
> }
> }
> }
> }
> private static boolean hasCxfModuleDependency(DeploymentUnit unit) {
> ModuleSpecification moduleSpec = (ModuleSpecification)unit.getAttachment(Attachments.MODULE_SPECIFICATION);
> for (ModuleDependency dep : moduleSpec.getUserDependencies()) {
> String id = dep.getIdentifier().getName();
> if (cxfExportingModules.contains(id)) {
> return true;
> }
> }
> return false;
> }
> The hasCxfModuleDependency() method checks a list of dependencies called userDependencies looking to see if there is an "org.apache.cxf" entry in the list.
> However, there is more than one list of module dependencies which are part of moduleSpec.
> private final List<ModuleDependency> systemDependencies = new ArrayList();
> private final List<ModuleDependency> localDependencies = new ArrayList();
> private final List<ModuleDependency> userDependencies = new ArrayList();
> I think when you have an exported dependency from the EAR level it may be part of one of the other dependency lists rather than in userDependencies, so what we have is well-meaning code that tries to check and make sure you have the right dependency to support your annotation (because normally missing annotation classes just fail silently so a check is useful to have), but I think it doesn't check everywhere that it should.
> Since the EAP 7.3.1 patch just came out, I installed that and repeated the test but there was no difference.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (WFWIP-337) Bootable JAR - Cloud - Add bindall interface, http(s) bound to bindall itf.
by Martin Choma (Jira)
[ https://issues.redhat.com/browse/WFWIP-337?page=com.atlassian.jira.plugin... ]
Martin Choma edited comment on WFWIP-337 at 9/9/20 8:38 AM:
------------------------------------------------------------
[~jdenise] Looking at resoulution of issue, but I am seeing still a lot of differences [1]
1.
-I am thinking if we arent exposing to much with this change. Socket bindings http, https, management are exposed to bindall in bootable jar. This is not the case in XP1 neither bare metal.
Shouldn't we align with other distributions standard configurations? -
Edited: I recall now we were talking images expose it to different adresses by modules. Eg.
https://github.com/wildfly/wildfly-cekit-modules/blob/master/jboss/contai... and
https://github.com/jboss-container-images/jboss-eap-modules/blob/master/j...
2.
Also instead of general `env.HOSTNAME` shouldn't we introduce more specific env. properties e.g. env.JBOSS_BIND_ADDRESS_PRIVATE, env.JBOSS_BIND_ADDRESS ?
3. shouldn't we remove ajp from cloud scenario to be aligned with XP cloud variant?
4.
Do you know what <outbound-socket-binding name="http-messaging"> in case of XP is and if we want it to be by default in bootable jar?
Seems to me it could be some support for messaging in conjuction with resource adapter standalone/deployments/activemq-rar.rar but we do not provide it by default anyway.
[1] !cloud-bootjar-vs-xp1.png|thumbnail!
was (Author: mchoma):
[~jdenise] Looking at resoulution of issue, but I am seeing still a lot of differences [1]
1.
I am thinking if we arent exposing to much with this change. Socket bindings http, https, management are exposed to bindall in bootable jar. This is not the case in XP1 neither bare metal.
Shouldn't we align with other distributions standard configurations?
2.
Also instead of general `env.HOSTNAME` shouldn't we introduce more specific env. properties e.g. env.JBOSS_BIND_ADDRESS_PRIVATE, env.JBOSS_BIND_ADDRESS ?
3. shouldn't we remove ajp from cloud scenario to be aligned with XP cloud variant?
4.
Do you know what <outbound-socket-binding name="http-messaging"> in case of XP is and if we want it to be by default in bootable jar?
Seems to me it could be some support for messaging in conjuction with resource adapter standalone/deployments/activemq-rar.rar but we do not provide it by default anyway.
[1] !cloud-bootjar-vs-xp1.png|thumbnail!
> Bootable JAR - Cloud - Add bindall interface, http(s) bound to bindall itf.
> ---------------------------------------------------------------------------
>
> Key: WFWIP-337
> URL: https://issues.redhat.com/browse/WFWIP-337
> Project: WildFly WIP
> Issue Type: Bug
> Reporter: Jean Francois Denise
> Assignee: Jean Francois Denise
> Priority: Major
> Attachments: cloud-bootjar-vs-xp1.png
>
>
> In S2i, the http socket binding is bound to 0.0.0.0. Currently in Bootable JAR it is bound to HOSTENV (if defined) and fallback to 127.0.0.1.
> We should align to S2I builder image by introducing the bindall interface and have http and https to use it.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (WFWIP-337) Bootable JAR - Cloud - Add bindall interface, http(s) bound to bindall itf.
by Martin Choma (Jira)
[ https://issues.redhat.com/browse/WFWIP-337?page=com.atlassian.jira.plugin... ]
Martin Choma commented on WFWIP-337:
------------------------------------
[~jdenise] Looking at resoulution of issue, but I am seeing still a lot of differences [1]
1.
I am thinking if we arent exposing to much with this change. Socket bindings http, https, management are exposed to bindall in bootable jar. This is not the case in XP1 neither bare metal.
Shouldn't we align with other distributions standard configurations?
2.
Also instead of general `env.HOSTNAME` shouldn't we introduce more specific env. properties e.g. env.JBOSS_BIND_ADDRESS_PRIVATE, env.JBOSS_BIND_ADDRESS ?
3. shouldn't we remove ajp from cloud scenario to be aligned with XP cloud variant?
4.
Do you know what <outbound-socket-binding name="http-messaging"> in case of XP is and if we want it to be by default in bootable jar?
Seems to me it could be some support for messaging in conjuction with resource adapter standalone/deployments/activemq-rar.rar but we do not provide it by default anyway.
[1] !cloud-bootjar-vs-xp1.png|thumbnail!
> Bootable JAR - Cloud - Add bindall interface, http(s) bound to bindall itf.
> ---------------------------------------------------------------------------
>
> Key: WFWIP-337
> URL: https://issues.redhat.com/browse/WFWIP-337
> Project: WildFly WIP
> Issue Type: Bug
> Reporter: Jean Francois Denise
> Assignee: Jean Francois Denise
> Priority: Major
> Attachments: cloud-bootjar-vs-xp1.png
>
>
> In S2i, the http socket binding is bound to 0.0.0.0. Currently in Bootable JAR it is bound to HOSTENV (if defined) and fallback to 127.0.0.1.
> We should align to S2I builder image by introducing the bindall interface and have http and https to use it.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (WFLY-13832) Bug in detecting the org.apache.cxf module
by Tomas Hofman (Jira)
[ https://issues.redhat.com/browse/WFLY-13832?page=com.atlassian.jira.plugi... ]
Tomas Hofman reassigned WFLY-13832:
-----------------------------------
Assignee: Tomas Hofman (was: Jim Ma)
> Bug in detecting the org.apache.cxf module
> ------------------------------------------
>
> Key: WFLY-13832
> URL: https://issues.redhat.com/browse/WFLY-13832
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 20.0.1.Final
> Reporter: Tomas Hofman
> Assignee: Tomas Hofman
> Priority: Major
>
> When deploying an EAR file which has a sub deployment that uses CXF annotation classes a warning is logged that looks like this:
> WFLYWS0065: Annotation '@org.apache.cxf.interceptor.OutInterceptors' found on class 'de.comdirect.application.mt.wsexample.server.SimpleWsServiceWS'. Perhaps you forgot to add a 'org.apache.cxf' module dependency to your deployment?
> If you declare a dependency on org.apache.cxf in the sub-deployment, the warning is not logged. However, if you declare the org.apache.cxf dependency at the EAR level with export=true you still get the message even though the CXF module should be visible.
> I tracked down the class org.jboss.as.webservices.deployers.WSClassVerificationProcessor located in the org/jboss/as/webservices/main/wildfly-webservices-server-integration-7.3.0.GA-redhat-00004.jar
> In this class there is a method which logs this message, plus an additional related method:
> private void verifyApacheCXFModuleDependencyRequirement(DeploymentUnit unit) {
> if (!hasCxfModuleDependency(unit)) {
>
> CompositeIndex index = (CompositeIndex)unit.getAttachment(Attachments.COMPOSITE_ANNOTATION_INDEX);
> DotName[] dotNames = \{ DotNames.WEB_SERVICE_ANNOTATION, DotNames.WEB_SERVICE_PROVIDER_ANNOTATION };
> for (DotName dotName : dotNames) {
> for (AnnotationInstance ai : index.getAnnotations(dotName)) {
> AnnotationTarget at = ai.target();
> if (at instanceof ClassInfo) {
> ClassInfo clazz = (ClassInfo)ai.target();
> for (DotName dn : clazz.annotations().keySet()) {
> if (dn.toString().startsWith("org.apache.cxf")) {
> WSLogger.ROOT_LOGGER.missingModuleDependency(dn.toString(), clazz.name().toString(), "org.apache.cxf");
> }
> }
> }
> }
> }
> }
> }
> private static boolean hasCxfModuleDependency(DeploymentUnit unit) {
> ModuleSpecification moduleSpec = (ModuleSpecification)unit.getAttachment(Attachments.MODULE_SPECIFICATION);
> for (ModuleDependency dep : moduleSpec.getUserDependencies()) {
> String id = dep.getIdentifier().getName();
> if (cxfExportingModules.contains(id)) {
> return true;
> }
> }
> return false;
> }
> The hasCxfModuleDependency() method checks a list of dependencies called userDependencies looking to see if there is an "org.apache.cxf" entry in the list.
> However, there is more than one list of module dependencies which are part of moduleSpec.
> private final List<ModuleDependency> systemDependencies = new ArrayList();
> private final List<ModuleDependency> localDependencies = new ArrayList();
> private final List<ModuleDependency> userDependencies = new ArrayList();
> I think when you have an exported dependency from the EAR level it may be part of one of the other dependency lists rather than in userDependencies, so what we have is well-meaning code that tries to check and make sure you have the right dependency to support your annotation (because normally missing annotation classes just fail silently so a check is useful to have), but I think it doesn't check everywhere that it should.
> Since the EAP 7.3.1 patch just came out, I installed that and repeated the test but there was no difference.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (WFLY-13832) Bug in detecting the org.apache.cxf module
by Tomas Hofman (Jira)
[ https://issues.redhat.com/browse/WFLY-13832?page=com.atlassian.jira.plugi... ]
Tomas Hofman updated WFLY-13832:
--------------------------------
Affects Version/s: 20.0.1.Final
> Bug in detecting the org.apache.cxf module
> ------------------------------------------
>
> Key: WFLY-13832
> URL: https://issues.redhat.com/browse/WFLY-13832
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 20.0.1.Final
> Reporter: Tomas Hofman
> Assignee: Jim Ma
> Priority: Major
>
> When deploying an EAR file which has a sub deployment that uses CXF annotation classes a warning is logged that looks like this:
> WFLYWS0065: Annotation '@org.apache.cxf.interceptor.OutInterceptors' found on class 'de.comdirect.application.mt.wsexample.server.SimpleWsServiceWS'. Perhaps you forgot to add a 'org.apache.cxf' module dependency to your deployment?
> If you declare a dependency on org.apache.cxf in the sub-deployment, the warning is not logged. However, if you declare the org.apache.cxf dependency at the EAR level with export=true you still get the message even though the CXF module should be visible.
> I tracked down the class org.jboss.as.webservices.deployers.WSClassVerificationProcessor located in the org/jboss/as/webservices/main/wildfly-webservices-server-integration-7.3.0.GA-redhat-00004.jar
> In this class there is a method which logs this message, plus an additional related method:
> private void verifyApacheCXFModuleDependencyRequirement(DeploymentUnit unit) {
> if (!hasCxfModuleDependency(unit)) {
>
> CompositeIndex index = (CompositeIndex)unit.getAttachment(Attachments.COMPOSITE_ANNOTATION_INDEX);
> DotName[] dotNames = \{ DotNames.WEB_SERVICE_ANNOTATION, DotNames.WEB_SERVICE_PROVIDER_ANNOTATION };
> for (DotName dotName : dotNames) {
> for (AnnotationInstance ai : index.getAnnotations(dotName)) {
> AnnotationTarget at = ai.target();
> if (at instanceof ClassInfo) {
> ClassInfo clazz = (ClassInfo)ai.target();
> for (DotName dn : clazz.annotations().keySet()) {
> if (dn.toString().startsWith("org.apache.cxf")) {
> WSLogger.ROOT_LOGGER.missingModuleDependency(dn.toString(), clazz.name().toString(), "org.apache.cxf");
> }
> }
> }
> }
> }
> }
> }
> private static boolean hasCxfModuleDependency(DeploymentUnit unit) {
> ModuleSpecification moduleSpec = (ModuleSpecification)unit.getAttachment(Attachments.MODULE_SPECIFICATION);
> for (ModuleDependency dep : moduleSpec.getUserDependencies()) {
> String id = dep.getIdentifier().getName();
> if (cxfExportingModules.contains(id)) {
> return true;
> }
> }
> return false;
> }
> The hasCxfModuleDependency() method checks a list of dependencies called userDependencies looking to see if there is an "org.apache.cxf" entry in the list.
> However, there is more than one list of module dependencies which are part of moduleSpec.
> private final List<ModuleDependency> systemDependencies = new ArrayList();
> private final List<ModuleDependency> localDependencies = new ArrayList();
> private final List<ModuleDependency> userDependencies = new ArrayList();
> I think when you have an exported dependency from the EAR level it may be part of one of the other dependency lists rather than in userDependencies, so what we have is well-meaning code that tries to check and make sure you have the right dependency to support your annotation (because normally missing annotation classes just fail silently so a check is useful to have), but I think it doesn't check everywhere that it should.
> Since the EAP 7.3.1 patch just came out, I installed that and repeated the test but there was no difference.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (WFLY-13832) Bug in detecting the org.apache.cxf module
by Tomas Hofman (Jira)
[ https://issues.redhat.com/browse/WFLY-13832?page=com.atlassian.jira.plugi... ]
Tomas Hofman moved JBEAP-20167 to WFLY-13832:
---------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-13832 (was: JBEAP-20167)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Web Services
(was: Web Services)
Affects Version/s: (was: 7.3.0.GA)
> Bug in detecting the org.apache.cxf module
> ------------------------------------------
>
> Key: WFLY-13832
> URL: https://issues.redhat.com/browse/WFLY-13832
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Reporter: Tomas Hofman
> Assignee: Jim Ma
> Priority: Major
>
> When deploying an EAR file which has a sub deployment that uses CXF annotation classes a warning is logged that looks like this:
> WFLYWS0065: Annotation '@org.apache.cxf.interceptor.OutInterceptors' found on class 'de.comdirect.application.mt.wsexample.server.SimpleWsServiceWS'. Perhaps you forgot to add a 'org.apache.cxf' module dependency to your deployment?
> If you declare a dependency on org.apache.cxf in the sub-deployment, the warning is not logged. However, if you declare the org.apache.cxf dependency at the EAR level with export=true you still get the message even though the CXF module should be visible.
> I tracked down the class org.jboss.as.webservices.deployers.WSClassVerificationProcessor located in the org/jboss/as/webservices/main/wildfly-webservices-server-integration-7.3.0.GA-redhat-00004.jar
> In this class there is a method which logs this message, plus an additional related method:
> private void verifyApacheCXFModuleDependencyRequirement(DeploymentUnit unit) {
> if (!hasCxfModuleDependency(unit)) {
>
> CompositeIndex index = (CompositeIndex)unit.getAttachment(Attachments.COMPOSITE_ANNOTATION_INDEX);
> DotName[] dotNames = \{ DotNames.WEB_SERVICE_ANNOTATION, DotNames.WEB_SERVICE_PROVIDER_ANNOTATION };
> for (DotName dotName : dotNames) {
> for (AnnotationInstance ai : index.getAnnotations(dotName)) {
> AnnotationTarget at = ai.target();
> if (at instanceof ClassInfo) {
> ClassInfo clazz = (ClassInfo)ai.target();
> for (DotName dn : clazz.annotations().keySet()) {
> if (dn.toString().startsWith("org.apache.cxf")) {
> WSLogger.ROOT_LOGGER.missingModuleDependency(dn.toString(), clazz.name().toString(), "org.apache.cxf");
> }
> }
> }
> }
> }
> }
> }
> private static boolean hasCxfModuleDependency(DeploymentUnit unit) {
> ModuleSpecification moduleSpec = (ModuleSpecification)unit.getAttachment(Attachments.MODULE_SPECIFICATION);
> for (ModuleDependency dep : moduleSpec.getUserDependencies()) {
> String id = dep.getIdentifier().getName();
> if (cxfExportingModules.contains(id)) {
> return true;
> }
> }
> return false;
> }
> The hasCxfModuleDependency() method checks a list of dependencies called userDependencies looking to see if there is an "org.apache.cxf" entry in the list.
> However, there is more than one list of module dependencies which are part of moduleSpec.
> private final List<ModuleDependency> systemDependencies = new ArrayList();
> private final List<ModuleDependency> localDependencies = new ArrayList();
> private final List<ModuleDependency> userDependencies = new ArrayList();
> I think when you have an exported dependency from the EAR level it may be part of one of the other dependency lists rather than in userDependencies, so what we have is well-meaning code that tries to check and make sure you have the right dependency to support your annotation (because normally missing annotation classes just fail silently so a check is useful to have), but I think it doesn't check everywhere that it should.
> Since the EAP 7.3.1 patch just came out, I installed that and repeated the test but there was no difference.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (DROOLS-5613) Disable Trusty pmml when jpmml is present
by Gabriele Cardosi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5613?page=com.atlassian.jira.plug... ]
Gabriele Cardosi closed DROOLS-5613.
------------------------------------
> Disable Trusty pmml when jpmml is present
> -----------------------------------------
>
> Key: DROOLS-5613
> URL: https://issues.redhat.com/browse/DROOLS-5613
> Project: Drools
> Issue Type: Task
> Reporter: Gabriele Cardosi
> Assignee: Gabriele Cardosi
> Priority: Blocker
> Labels: TrustyAI
>
> Inside trusty PMMLAssembler:
> 1. copy/refactor isjPMMLAvailableToClassLoader (from legacy PMMLAssembler)
> 2. modify
> {code:java}
> private static boolean isToEnable()
> {code}
> to always return "false" when jpmml is present
> Inside legacy PMMLAssembler:
> 1. modify
> {code:java}
> private static boolean isToEnable()
> {code}
> to always return "false" when jpmml is present
> 2. remove isjPMMLAvailableToClassLoader invocation from
> {code:java}
> private void addPackage(Resource resource)
> {code}
> 3. modify isjPMMLAvailableToClassLoader to log when jpmml is present
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (WFWIP-330) Bootable JAR - Cloud - No HA support in default configuration.
by Martin Choma (Jira)
[ https://issues.redhat.com/browse/WFWIP-330?page=com.atlassian.jira.plugin... ]
Martin Choma closed WFWIP-330.
------------------------------
I can verify issue was resolved in wildfly-jar-maven-plugin version Beta6.
> Bootable JAR - Cloud - No HA support in default configuration.
> --------------------------------------------------------------
>
> Key: WFWIP-330
> URL: https://issues.redhat.com/browse/WFWIP-330
> Project: WildFly WIP
> Issue Type: Bug
> Reporter: Jean Francois Denise
> Assignee: Jean Francois Denise
> Priority: Major
>
> When no Galleon Layers are provisioned, the default configuration standalone-microprofile.xml is used. For cloud, having an HA configuration makes more sense.
> The Bootable JAR maven plugin should provision a standalone-microprofile-ha.xml
> NB: HA features are enabled for WildFly/EAP/XP S2I builder image default configurations.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months