[JBoss JIRA] (WFLY-4419) Dependency on a deployed CDI module - beans are not injected
by Dirk Buchhorn (JIRA)
[ https://issues.jboss.org/browse/WFLY-4419?page=com.atlassian.jira.plugin.... ]
Dirk Buchhorn commented on WFLY-4419:
-------------------------------------
I deploy my test files to Wildfly 9 Beta2 and it works. In the past I do all my tests with Wildfly 8.2. Which Wildfly version do you use for your test?
> Dependency on a deployed CDI module - beans are not injected
> ------------------------------------------------------------
>
> Key: WFLY-4419
> URL: https://issues.jboss.org/browse/WFLY-4419
> Project: WildFly
> Issue Type: Feature Request
> Components: CDI / Weld
> Affects Versions: 8.2.0.Final
> Reporter: Dirk Buchhorn
> Assignee: Stuart Douglas
>
> I want to deploy two modules to wildfly 8.2.0 The module-a contains beans (and later CDI producer and other stuff) and module-b use this beans. Beans from module-a should be injected with CDI in module-b (There is a beans.xml in both modules.). All works fine if the module-a is direct referenced as dependency like this:
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
> <deployment>
> <dependencies>
> <module name="deployment.module-a-1.0.0.jar" meta-inf="import" />
> </dependencies>
> </deployment>
> </jboss-deployment-structure>
>
> But the dependency to module-a should be without to know the deployed version, so I tried to set a module alias and (or) to re-export module-a under a different name like this.
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
> <deployment>
> <module-alias name="deployment.module-a-alias" />
> </deployment>
> </jboss-deployment-structure>
>
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
> <module name="deployment.module-a">
> <module-alias name="deployment.module-a-alias" />
> <dependencies>
> <module name="deployment.module-a-1.0.0.jar" export="true" meta-inf="export" />
> </dependencies>
> </module>
> </jboss-deployment-structure>
>
> But either the module alias or a re-export under a new module name worked. The reported exception is always:
> Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type XYZ with qualifiers @Default
>
> The module alias fit my requirements and I guess is should work with CDI but it dosn't.
> Two questions:
> - Why CDI don't work with module alias and module re-export?
> - How to deal with dependencies and module versions?
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (WFLY-4419) Dependency on a deployed CDI module - beans are not injected
by Dirk Buchhorn (JIRA)
[ https://issues.jboss.org/browse/WFLY-4419?page=com.atlassian.jira.plugin.... ]
Dirk Buchhorn commented on WFLY-4419:
-------------------------------------
You can download a small multi maven module from here: https://www.dropbox.com/s/xaon4hfpklz5dx9/cdi-test.zip
> Dependency on a deployed CDI module - beans are not injected
> ------------------------------------------------------------
>
> Key: WFLY-4419
> URL: https://issues.jboss.org/browse/WFLY-4419
> Project: WildFly
> Issue Type: Feature Request
> Components: CDI / Weld
> Affects Versions: 8.2.0.Final
> Reporter: Dirk Buchhorn
> Assignee: Stuart Douglas
>
> I want to deploy two modules to wildfly 8.2.0 The module-a contains beans (and later CDI producer and other stuff) and module-b use this beans. Beans from module-a should be injected with CDI in module-b (There is a beans.xml in both modules.). All works fine if the module-a is direct referenced as dependency like this:
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
> <deployment>
> <dependencies>
> <module name="deployment.module-a-1.0.0.jar" meta-inf="import" />
> </dependencies>
> </deployment>
> </jboss-deployment-structure>
>
> But the dependency to module-a should be without to know the deployed version, so I tried to set a module alias and (or) to re-export module-a under a different name like this.
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
> <deployment>
> <module-alias name="deployment.module-a-alias" />
> </deployment>
> </jboss-deployment-structure>
>
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
> <module name="deployment.module-a">
> <module-alias name="deployment.module-a-alias" />
> <dependencies>
> <module name="deployment.module-a-1.0.0.jar" export="true" meta-inf="export" />
> </dependencies>
> </module>
> </jboss-deployment-structure>
>
> But either the module alias or a re-export under a new module name worked. The reported exception is always:
> Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type XYZ with qualifiers @Default
>
> The module alias fit my requirements and I guess is should work with CDI but it dosn't.
> Two questions:
> - Why CDI don't work with module alias and module re-export?
> - How to deal with dependencies and module versions?
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (WFLY-3988) Authorization denied for authenticated users when @PermitAll is used on EJB JAX-WS endpoint
by Jim Ma (JIRA)
[ https://issues.jboss.org/browse/WFLY-3988?page=com.atlassian.jira.plugin.... ]
Jim Ma commented on WFLY-3988:
------------------------------
To calarify a bit for this issue:
For the above annoated ejb class, only the users with a role found in @DelareRoles can invoke c() is expected. Alessio's suggestion let me find another issue : the @PermitAll annotated on class level doesn't work.
My change fixed this issue and enable all authorized user to do ejb container's security check. Without this fix, authroization for @PermitAll on class level or no class level security annotation doesn't work properly.
> Authorization denied for authenticated users when @PermitAll is used on EJB JAX-WS endpoint
> -------------------------------------------------------------------------------------------
>
> Key: WFLY-3988
> URL: https://issues.jboss.org/browse/WFLY-3988
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 8.1.0.Final
> Reporter: Kyle Lape
> Assignee: Jim Ma
> Fix For: 9.0.0.Beta1
>
>
> Given this endpoint:
> {code:java}
> @Stateless
> @WebService(endpointInterface="com.redhat.gss.SecureEndpoint")
> @DeclareRoles({"a","b"})
> @WebContext(contextRoot="/endpoint",urlPattern="/e",authMethod="BASIC")
> public class SecureEndpointE implements SecureEndpoint {
> @RolesAllowed({"a"})
> public String a() {
> return "Success";
> }
> @RolesAllowed({"b"})
> public String b() {
> return "Success";
> }
> @PermitAll
> public String c() {
> return "Success";
> }
> }
> {code}
> One would expect any authenticated user to be able to invoke {{c()}}, but only users with a role found in {{@DelareRoles}} can invoke it.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (ELY-173) Clean up javadoc warnings
by Darran Lofthouse (JIRA)
Darran Lofthouse created ELY-173:
------------------------------------
Summary: Clean up javadoc warnings
Key: ELY-173
URL: https://issues.jboss.org/browse/ELY-173
Project: WildFly Elytron
Issue Type: Task
Components: Build
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 1.0.0.Alpha1
{noformat}
[WARNING] Javadoc Warnings
[WARNING] /home/darranl/src/wildfly9/wildfly-elytron/src/main/java/org/wildfly/security/sasl/entity/Entity.java:50: warning - @param argument "algorithm" is not a parameter name.
[WARNING] /home/darranl/src/wildfly9/wildfly-elytron/src/main/java/org/wildfly/security/sasl/entity/Entity.java:66: warning - @param argument "algorithm" is not a parameter name.
[WARNING] /home/darranl/src/wildfly9/wildfly-elytron/src/main/java/org/wildfly/security/auth/provider/ldap/DirContextFactory.java:49: warning - Tag @link: reference not found: InitialDirContext
[WARNING] /home/darranl/src/wildfly9/wildfly-elytron/src/main/java/org/wildfly/security/password/interfaces/DigestPassword.java:60: warning - Tag @link: reference not found: Password
[WARNING] /home/darranl/src/wildfly9/wildfly-elytron/src/main/java/org/wildfly/security/password/interfaces/DigestPassword.java:53: warning - Tag @link: reference not found: Password
[WARNING] /home/darranl/src/wildfly9/wildfly-elytron/src/main/java/org/wildfly/security/password/interfaces/DigestPassword.java:43: warning - Tag @link: reference not found: Password
[WARNING] /home/darranl/src/wildfly9/wildfly-elytron/src/main/java/org/wildfly/security/password/interfaces/DigestPassword.java:43: warning - Tag @link: reference not found: Password
[WARNING] /home/darranl/src/wildfly9/wildfly-elytron/src/main/java/org/wildfly/security/password/interfaces/DigestPassword.java:43: warning - Tag @link: reference not found: Password
[WARNING] /home/darranl/src/wildfly9/wildfly-elytron/src/main/java/org/wildfly/security/password/interfaces/DigestPassword.java:43: warning - Tag @link: reference not found: Password
[WARNING] /home/darranl/src/wildfly9/wildfly-elytron/src/main/java/org/wildfly/security/password/interfaces/DigestPassword.java:43: warning - Tag @link: reference not found: Password
[WARNING] /home/darranl/src/wildfly9/wildfly-elytron/src/main/java/org/wildfly/security/password/interfaces/DigestPassword.java:53: warning - Tag @link: reference not found: Password
[WARNING] /home/darranl/src/wildfly9/wildfly-elytron/src/main/java/org/wildfly/security/password/interfaces/DigestPassword.java:53: warning - Tag @link: reference not found: Password
[WARNING] /home/darranl/src/wildfly9/wildfly-elytron/src/main/java/org/wildfly/security/password/interfaces/DigestPassword.java:53: warning - Tag @link: reference not found: Password
[WARNING] /home/darranl/src/wildfly9/wildfly-elytron/src/main/java/org/wildfly/security/password/interfaces/DigestPassword.java:60: warning - Tag @link: reference not found: Password
[WARNING] /home/darranl/src/wildfly9/wildfly-elytron/src/main/java/org/wildfly/security/password/interfaces/DigestPassword.java:60: warning - Tag @link: reference not found: Password
[WARNING] /home/darranl/src/wildfly9/wildfly-elytron/src/main/java/org/wildfly/security/manager/package-info.java:27: warning - Tag @link: reference not found: WildFlySecurityManager#install()
[WARNING] /home/darranl/src/wildfly9/wildfly-elytron/src/main/java/org/wildfly/security/password/interfaces/DigestPassword.java:60: warning - Tag @link: reference not found: Password
[WARNING] /home/darranl/src/wildfly9/wildfly-elytron/src/main/java/org/wildfly/security/password/interfaces/DigestPassword.java:53: warning - Tag @link: reference not found: Password
[WARNING] /home/darranl/src/wildfly9/wildfly-elytron/src/main/java/org/wildfly/security/password/interfaces/DigestPassword.java:43: warning - Tag @link: reference not found: Password
[WARNING] javadoc: warning - Cannot run program "dot": error=2, No such file or directory
[WARNING] javadoc: warning - Graphviz is not found.
[WARNING] javadoc: warning - Please install graphviz and specify -Dgraphviz.home Otherwise, you might have specified incorrect graphviz home Graphviz is not found in the system path.
[WARNING] javadoc: warning - Skipping diagram generation.
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (WFLY-4474) Container-provided security role "**" (EJB 3.2) not working
by Jan Martiska (JIRA)
[ https://issues.jboss.org/browse/WFLY-4474?page=com.atlassian.jira.plugin.... ]
Jan Martiska updated WFLY-4474:
-------------------------------
Summary: Container-provided security role "**" (EJB 3.2) not working (was: Container-provided security role "*" (EJB 3.2) not working)
> Container-provided security role "**" (EJB 3.2) not working
> -----------------------------------------------------------
>
> Key: WFLY-4474
> URL: https://issues.jboss.org/browse/WFLY-4474
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 9.0.0.Beta1
> Reporter: Jan Martiska
> Assignee: Stuart Douglas
>
> EJB 3.2 12.3.1 Security Roles:
> {quote}
> A security role with the name “**” is defined by the Container, and is intended to be used by the Bean
> Provider, Application Assembler, or Deployer to indicate that the caller must log on or authenticate to
> invoke a method or to perform some processing requiring membership in this container role. This con-
> tainer security role indicates that authentication, without consideration of role membership, is required.
> {quote}
> This doesn't seem to work in WildFly 9.0.0.Beta1. An authenticated user trying to invoke methods annotated @PermitAll("**") gets an EJBAccessException.
> I started preparing tests for this behavior at https://github.com/jmartisk/wildfly/commits/master-ejb32tests-starrole
> It causes failures in:
> InherritanceAnnSFSBTestCase.testSingleMethodAnnotationsUser1
> InherritanceAnnSLSBTestCase.testSingleMethodAnnotationsUser1
> InjectionAnnSFSBtoSFSBTestCase.testSingleMethodAnnotationsUser1
> InjectionAnnSFSBtoSLSBTestCase.testSingleMethodAnnotationsUser1
> InjectionAnnSLSBtoSFSBTestCase.testSingleMethodAnnotationsUser1
> InjectionAnnSLSBtoSLSBTestCase.testSingleMethodAnnotationsUser1
> SingleMethodsAnnSFSBTestCase.testSingleMethodAnnotationsUser1
> SingleMethodsAnnSLSBTestCase.testSingleMethodAnnotationsUser1
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (WFLY-4474) Container-provided security role "*" (EJB 3.2) not working
by Jan Martiska (JIRA)
[ https://issues.jboss.org/browse/WFLY-4474?page=com.atlassian.jira.plugin.... ]
Jan Martiska updated WFLY-4474:
-------------------------------
Description:
EJB 3.2 12.3.1 Security Roles:
{quote}
A security role with the name “**” is defined by the Container, and is intended to be used by the Bean
Provider, Application Assembler, or Deployer to indicate that the caller must log on or authenticate to
invoke a method or to perform some processing requiring membership in this container role. This con-
tainer security role indicates that authentication, without consideration of role membership, is required.
{quote}
This doesn't seem to work in WildFly 9.0.0.Beta1. An authenticated user trying to invoke methods annotated @PermitAll("**") gets an EJBAccessException.
I started preparing tests for this behavior at https://github.com/jmartisk/wildfly/commits/master-ejb32tests-starrole
It causes failures in:
InherritanceAnnSFSBTestCase.testSingleMethodAnnotationsUser1
InherritanceAnnSLSBTestCase.testSingleMethodAnnotationsUser1
InjectionAnnSFSBtoSFSBTestCase.testSingleMethodAnnotationsUser1
InjectionAnnSFSBtoSLSBTestCase.testSingleMethodAnnotationsUser1
InjectionAnnSLSBtoSFSBTestCase.testSingleMethodAnnotationsUser1
InjectionAnnSLSBtoSLSBTestCase.testSingleMethodAnnotationsUser1
SingleMethodsAnnSFSBTestCase.testSingleMethodAnnotationsUser1
SingleMethodsAnnSLSBTestCase.testSingleMethodAnnotationsUser1
was:
EJB 3.2 12.3.1 Security Roles:
{quote}
A security role with the name “**” is defined by the Container, and is intended to be used by the Bean
Provider, Application Assembler, or Deployer to indicate that the caller must log on or authenticate to
invoke a method or to perform some processing requiring membership in this container role. This con-
tainer security role indicates that authentication, without consideration of role membership, is required.
{quote}
This doesn't seem to work in WildFly 9.0.0.Beta1. An authenticated user trying to invoke methods annotated @PermitAll("*") gets an EJBAccessException.
I started preparing tests for this behavior at https://github.com/jmartisk/wildfly/commits/master-ejb32tests-starrole
It causes failures in:
InherritanceAnnSFSBTestCase.testSingleMethodAnnotationsUser1
InherritanceAnnSLSBTestCase.testSingleMethodAnnotationsUser1
InjectionAnnSFSBtoSFSBTestCase.testSingleMethodAnnotationsUser1
InjectionAnnSFSBtoSLSBTestCase.testSingleMethodAnnotationsUser1
InjectionAnnSLSBtoSFSBTestCase.testSingleMethodAnnotationsUser1
InjectionAnnSLSBtoSLSBTestCase.testSingleMethodAnnotationsUser1
SingleMethodsAnnSFSBTestCase.testSingleMethodAnnotationsUser1
SingleMethodsAnnSLSBTestCase.testSingleMethodAnnotationsUser1
> Container-provided security role "*" (EJB 3.2) not working
> ----------------------------------------------------------
>
> Key: WFLY-4474
> URL: https://issues.jboss.org/browse/WFLY-4474
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 9.0.0.Beta1
> Reporter: Jan Martiska
> Assignee: Stuart Douglas
>
> EJB 3.2 12.3.1 Security Roles:
> {quote}
> A security role with the name “**” is defined by the Container, and is intended to be used by the Bean
> Provider, Application Assembler, or Deployer to indicate that the caller must log on or authenticate to
> invoke a method or to perform some processing requiring membership in this container role. This con-
> tainer security role indicates that authentication, without consideration of role membership, is required.
> {quote}
> This doesn't seem to work in WildFly 9.0.0.Beta1. An authenticated user trying to invoke methods annotated @PermitAll("**") gets an EJBAccessException.
> I started preparing tests for this behavior at https://github.com/jmartisk/wildfly/commits/master-ejb32tests-starrole
> It causes failures in:
> InherritanceAnnSFSBTestCase.testSingleMethodAnnotationsUser1
> InherritanceAnnSLSBTestCase.testSingleMethodAnnotationsUser1
> InjectionAnnSFSBtoSFSBTestCase.testSingleMethodAnnotationsUser1
> InjectionAnnSFSBtoSLSBTestCase.testSingleMethodAnnotationsUser1
> InjectionAnnSLSBtoSFSBTestCase.testSingleMethodAnnotationsUser1
> InjectionAnnSLSBtoSLSBTestCase.testSingleMethodAnnotationsUser1
> SingleMethodsAnnSFSBTestCase.testSingleMethodAnnotationsUser1
> SingleMethodsAnnSLSBTestCase.testSingleMethodAnnotationsUser1
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (DROOLS-754) KieScanner crash while erroneously trying to resolve non necessary dependencies
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-754?page=com.atlassian.jira.plugin... ]
Matteo Mortari commented on DROOLS-754:
---------------------------------------
[ I've taken the liberty of changing priority which is not certainly major given a workaround, although possibly not ideal in some installations, do actually exists].
> KieScanner crash while erroneously trying to resolve non necessary dependencies
> -------------------------------------------------------------------------------
>
> Key: DROOLS-754
> URL: https://issues.jboss.org/browse/DROOLS-754
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.2.0.Final
> Environment: kie-ci
> Reporter: Matteo Mortari
> Assignee: Mario Fusco
> Priority: Minor
> Attachments: 20150331.DROOLS-754.zip
>
>
> h5. Overview
> Given kie.maven.settings.custom to force KIE libraries to reference only an internal nexus repo without Maven-central proxy just for the kjar of the rules.
> Given a KieContainer created with ReleaseId, trying to create a KieScanner would fail if the kjar of the release ID contain parametrized versions in the POM, because the KiScanner does not substitute the parameter, and moreover it tries to resolve them anyway even if those dependencies are not actually needed because having scope=test.
> Even changing the internal nexus repo, althought may not be feasible, for Maven-central proxy (http://repo1.maven.org/maven2/) would fail in resolving other dependencies.
> *keypoint*: have a way to instruct KIE KieContainer AND KieScanner, to reference just-and-only an internal Nexus repo just and only for the KJar for the rules, without having to internally proxy or double-check Maven central, please?
> Could you kindly advise accordingly, please?
> h5. Details
> Given a kjar artifact named {{kiescanner-testandversionissue-rules}} with the following pom (extract):
> {code:xml}
> <properties>
> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
> <drools-version>6.2.0.Final</drools-version>
> <slf4j-version>1.7.2</slf4j-version>
> <junit-version>4.11</junit-version>
> </properties>
>
> <dependencyManagement>
> <dependencies>
> <dependency>
> <groupId>org.drools</groupId>
> <artifactId>drools-bom</artifactId>
> <type>pom</type>
> <version>${drools-version}</version>
> <scope>import</scope>
> </dependency>
> </dependencies>
> </dependencyManagement>
> <dependencies>
>
> <dependency>
> <groupId>org.drools</groupId>
> <artifactId>drools-compiler</artifactId>
> <scope>test</scope>
> </dependency>
> <dependency>
> <groupId>junit</groupId>
> <artifactId>junit</artifactId>
> <version>${junit-version}</version>
> <scope>test</scope>
> </dependency>
> <dependency>
> <groupId>org.slf4j</groupId>
> <artifactId>slf4j-log4j12</artifactId>
> <version>${slf4j-version}</version>
> <scope>test</scope>
> </dependency>
> </dependencies>
> {code}
> Please notice the dependencies are parametrized in the versions, and moreover are not really required for runtime because scope=test.
> Now assume this kjar is deployed to a maven repo, like a nexus repository.
> Now given a client application havign kie.maven.settings.custom to force KIE libraries to reference only an internal nexus repo:
> {code}
> ReleaseId rId = kieServices.newReleaseId( "com.acme", "kiescanner-testandversionissue-rules", "RELEASE" );
> KieContainer kieContainer = kieServices.newKieContainer( rId );
> LOG.info("kieContainer exists. {}", kieContainer);
> LOG.info("Now about to create kieScanner...");
> KieScanner kScanner = kieServices.newKieScanner( kieContainer );
> kScanner.start( KIE_SCANNER_INTERVAL );
> {code}
> This code will fail with the following in the log (extract):
> {code}
> INFO [com.acme.kiescanner_testandversionissue_client.App] (main) kieContainer exists. org.drools.compiler.kie.builder.impl.KieContainerImpl@1229a2b7
> INFO [com.acme.kiescanner_testandversionissue_client.App] (main) Now about to create kieScanner...
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Sending request: GET /nexus/content/groups/public/org/slf4j/slf4j-log4j12/$%7Bslf4j-version%7D/slf4j-log4j12-$%7Bslf4j-version%7D.pom HTTP/1.1
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Receiving response: HTTP/1.1 404 Not Found
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Connection 0.0.0.0:56971<->127.0.0.1:8081 closed
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Connection 0.0.0.0:56971<->127.0.0.1:8081 closed
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Sending request: GET /nexus/content/groups/public/junit/junit/$%7Bjunit-version%7D/junit-$%7Bjunit-version%7D.pom HTTP/1.1
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Receiving response: HTTP/1.1 404 Not Found
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Connection 0.0.0.0:56972<->127.0.0.1:8081 closed
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Connection 0.0.0.0:56972<->127.0.0.1:8081 closed
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Sending request: GET /nexus/content/groups/public/org/drools/drools-bom/$%7Bdrools-version%7D/drools-bom-$%7Bdrools-version%7D.pom HTTP/1.1
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Receiving response: HTTP/1.1 404 Not Found
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Connection 0.0.0.0:56973<->127.0.0.1:8081 closed
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Connection 0.0.0.0:56973<->127.0.0.1:8081 closed
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Sending request: GET /nexus/content/groups/public/org/slf4j/slf4j-log4j12/$%7Bslf4j-version%7D/slf4j-log4j12-$%7Bslf4j-version%7D.jar HTTP/1.1
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Receiving response: HTTP/1.1 404 Not Found
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Connection 0.0.0.0:56974<->127.0.0.1:8081 closed
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Connection 0.0.0.0:56974<->127.0.0.1:8081 closed
> WARN [org.kie.scanner.MavenRepository] (main) Unable to resolve artifact: org.slf4j:slf4j-log4j12:${slf4j-version}
> {code}
> We can notice two issues:
> * the ${...-version} is not substitued while trying to resolve these artifacts on the nexus repo, the URL contains the ${...-version} literally
> * actually why the KieScanner try to resolve them given the dependencies are scope=test ?
> Also, even changing the internal nexus repo for Maven-central proxy (http://repo1.maven.org/maven2/) by:
> nexus connect with default user admin/admin123, add proxy repo http://repo1.maven.org/maven2/), go to group "public" and add the proxy, erase local-user .m2 drools-bom to force re-resolution,
> And re-running the client application again, would instead crash in resolving the following:
> {code}
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Sending request: HEAD /nexus/content/groups/public/org/jboss/dashboard-builder/dashboard-builder-bom/6.2.0.Final/dashboard-builder-bom-6.2.0.Final.pom HTTP/1.1
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Receiving response: HTTP/1.1 404 Not Found
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Connection 0.0.0.0:57598<->127.0.0.1:8081 closed
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Connection 0.0.0.0:57598<->127.0.0.1:8081 closed
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Sending request: HEAD /nexus/content/groups/public/org/dashbuilder/dashbuilder-bom/0.2.1.Final/dashbuilder-bom-0.2.1.Final.pom HTTP/1.1
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Receiving response: HTTP/1.1 404 Not Found
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Connection 0.0.0.0:57599<->127.0.0.1:8081 closed
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Connection 0.0.0.0:57599<->127.0.0.1:8081 closed
> {code}
> Could you kindly advise accordingly, please?
> h5. Conclusion
> Have a way to instruct KIE KieContainer AND KieScanner, to reference just-and-only an internal Nexus repo just and only for the KJar for the rules, without having to proxy Maven central
> Please notice:
> IFF in the custom kie-settings.xml I do remove the mirror definition, the problem WILL be that KIE libraries will try to resolve the {{kiescanner-testandversionissue-rules}} kjar in *both* Maven central and the local repo, and this is not advisable as the rule package name should go straight and just to the internal maven repo.
> h5. Steps to reproduce
> I will attach reproducer containing
> * kiescanner-testandversionissue-rules
> * kiescanner-testandversionissue-client
> * standalone nexus containing just and only repo for the kjar rules without any Maven-central proxy
> you can use the last for standalone test, otherwise you can deploy the rule and reference to another disposable internal Nexus repo by also updating the custom kie-settings.xml in the client app.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (DROOLS-754) KieScanner crash while erroneously trying to resolve non necessary dependencies
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-754?page=com.atlassian.jira.plugin... ]
Matteo Mortari commented on DROOLS-754:
---------------------------------------
*Workaround*: on the internal Maven repo custom Nexus repo indicated in the custom kie-settings.xml, do proxy not only Maven central, but ALSO JBoss repository (at the time writing: http://repository.jboss.org/nexus/content/groups/public/). Doing so, would not fail in resolving the dependencies for /org/jboss/dashboard-builder/dashboard-builder-bom and org/dashbuilder/dashbuilder-bom, hence it will work.
However as mentioned it could not be possible to have the internal Maven repo / custom Nexus repo to also do the proxy, if the business need it only and just for kjar store?
> KieScanner crash while erroneously trying to resolve non necessary dependencies
> -------------------------------------------------------------------------------
>
> Key: DROOLS-754
> URL: https://issues.jboss.org/browse/DROOLS-754
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.2.0.Final
> Environment: kie-ci
> Reporter: Matteo Mortari
> Assignee: Mario Fusco
> Attachments: 20150331.DROOLS-754.zip
>
>
> h5. Overview
> Given kie.maven.settings.custom to force KIE libraries to reference only an internal nexus repo without Maven-central proxy just for the kjar of the rules.
> Given a KieContainer created with ReleaseId, trying to create a KieScanner would fail if the kjar of the release ID contain parametrized versions in the POM, because the KiScanner does not substitute the parameter, and moreover it tries to resolve them anyway even if those dependencies are not actually needed because having scope=test.
> Even changing the internal nexus repo, althought may not be feasible, for Maven-central proxy (http://repo1.maven.org/maven2/) would fail in resolving other dependencies.
> *keypoint*: have a way to instruct KIE KieContainer AND KieScanner, to reference just-and-only an internal Nexus repo just and only for the KJar for the rules, without having to internally proxy or double-check Maven central, please?
> Could you kindly advise accordingly, please?
> h5. Details
> Given a kjar artifact named {{kiescanner-testandversionissue-rules}} with the following pom (extract):
> {code:xml}
> <properties>
> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
> <drools-version>6.2.0.Final</drools-version>
> <slf4j-version>1.7.2</slf4j-version>
> <junit-version>4.11</junit-version>
> </properties>
>
> <dependencyManagement>
> <dependencies>
> <dependency>
> <groupId>org.drools</groupId>
> <artifactId>drools-bom</artifactId>
> <type>pom</type>
> <version>${drools-version}</version>
> <scope>import</scope>
> </dependency>
> </dependencies>
> </dependencyManagement>
> <dependencies>
>
> <dependency>
> <groupId>org.drools</groupId>
> <artifactId>drools-compiler</artifactId>
> <scope>test</scope>
> </dependency>
> <dependency>
> <groupId>junit</groupId>
> <artifactId>junit</artifactId>
> <version>${junit-version}</version>
> <scope>test</scope>
> </dependency>
> <dependency>
> <groupId>org.slf4j</groupId>
> <artifactId>slf4j-log4j12</artifactId>
> <version>${slf4j-version}</version>
> <scope>test</scope>
> </dependency>
> </dependencies>
> {code}
> Please notice the dependencies are parametrized in the versions, and moreover are not really required for runtime because scope=test.
> Now assume this kjar is deployed to a maven repo, like a nexus repository.
> Now given a client application havign kie.maven.settings.custom to force KIE libraries to reference only an internal nexus repo:
> {code}
> ReleaseId rId = kieServices.newReleaseId( "com.acme", "kiescanner-testandversionissue-rules", "RELEASE" );
> KieContainer kieContainer = kieServices.newKieContainer( rId );
> LOG.info("kieContainer exists. {}", kieContainer);
> LOG.info("Now about to create kieScanner...");
> KieScanner kScanner = kieServices.newKieScanner( kieContainer );
> kScanner.start( KIE_SCANNER_INTERVAL );
> {code}
> This code will fail with the following in the log (extract):
> {code}
> INFO [com.acme.kiescanner_testandversionissue_client.App] (main) kieContainer exists. org.drools.compiler.kie.builder.impl.KieContainerImpl@1229a2b7
> INFO [com.acme.kiescanner_testandversionissue_client.App] (main) Now about to create kieScanner...
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Sending request: GET /nexus/content/groups/public/org/slf4j/slf4j-log4j12/$%7Bslf4j-version%7D/slf4j-log4j12-$%7Bslf4j-version%7D.pom HTTP/1.1
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Receiving response: HTTP/1.1 404 Not Found
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Connection 0.0.0.0:56971<->127.0.0.1:8081 closed
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Connection 0.0.0.0:56971<->127.0.0.1:8081 closed
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Sending request: GET /nexus/content/groups/public/junit/junit/$%7Bjunit-version%7D/junit-$%7Bjunit-version%7D.pom HTTP/1.1
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Receiving response: HTTP/1.1 404 Not Found
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Connection 0.0.0.0:56972<->127.0.0.1:8081 closed
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Connection 0.0.0.0:56972<->127.0.0.1:8081 closed
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Sending request: GET /nexus/content/groups/public/org/drools/drools-bom/$%7Bdrools-version%7D/drools-bom-$%7Bdrools-version%7D.pom HTTP/1.1
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Receiving response: HTTP/1.1 404 Not Found
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Connection 0.0.0.0:56973<->127.0.0.1:8081 closed
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Connection 0.0.0.0:56973<->127.0.0.1:8081 closed
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Sending request: GET /nexus/content/groups/public/org/slf4j/slf4j-log4j12/$%7Bslf4j-version%7D/slf4j-log4j12-$%7Bslf4j-version%7D.jar HTTP/1.1
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Receiving response: HTTP/1.1 404 Not Found
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Connection 0.0.0.0:56974<->127.0.0.1:8081 closed
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Connection 0.0.0.0:56974<->127.0.0.1:8081 closed
> WARN [org.kie.scanner.MavenRepository] (main) Unable to resolve artifact: org.slf4j:slf4j-log4j12:${slf4j-version}
> {code}
> We can notice two issues:
> * the ${...-version} is not substitued while trying to resolve these artifacts on the nexus repo, the URL contains the ${...-version} literally
> * actually why the KieScanner try to resolve them given the dependencies are scope=test ?
> Also, even changing the internal nexus repo for Maven-central proxy (http://repo1.maven.org/maven2/) by:
> nexus connect with default user admin/admin123, add proxy repo http://repo1.maven.org/maven2/), go to group "public" and add the proxy, erase local-user .m2 drools-bom to force re-resolution,
> And re-running the client application again, would instead crash in resolving the following:
> {code}
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Sending request: HEAD /nexus/content/groups/public/org/jboss/dashboard-builder/dashboard-builder-bom/6.2.0.Final/dashboard-builder-bom-6.2.0.Final.pom HTTP/1.1
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Receiving response: HTTP/1.1 404 Not Found
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Connection 0.0.0.0:57598<->127.0.0.1:8081 closed
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Connection 0.0.0.0:57598<->127.0.0.1:8081 closed
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Sending request: HEAD /nexus/content/groups/public/org/dashbuilder/dashbuilder-bom/0.2.1.Final/dashbuilder-bom-0.2.1.Final.pom HTTP/1.1
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Receiving response: HTTP/1.1 404 Not Found
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Connection 0.0.0.0:57599<->127.0.0.1:8081 closed
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Connection 0.0.0.0:57599<->127.0.0.1:8081 closed
> {code}
> Could you kindly advise accordingly, please?
> h5. Conclusion
> Have a way to instruct KIE KieContainer AND KieScanner, to reference just-and-only an internal Nexus repo just and only for the KJar for the rules, without having to proxy Maven central
> Please notice:
> IFF in the custom kie-settings.xml I do remove the mirror definition, the problem WILL be that KIE libraries will try to resolve the {{kiescanner-testandversionissue-rules}} kjar in *both* Maven central and the local repo, and this is not advisable as the rule package name should go straight and just to the internal maven repo.
> h5. Steps to reproduce
> I will attach reproducer containing
> * kiescanner-testandversionissue-rules
> * kiescanner-testandversionissue-client
> * standalone nexus containing just and only repo for the kjar rules without any Maven-central proxy
> you can use the last for standalone test, otherwise you can deploy the rule and reference to another disposable internal Nexus repo by also updating the custom kie-settings.xml in the client app.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years
[JBoss JIRA] (DROOLS-754) KieScanner crash while erroneously trying to resolve non necessary dependencies
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-754?page=com.atlassian.jira.plugin... ]
Matteo Mortari updated DROOLS-754:
----------------------------------
Priority: Minor (was: Major)
> KieScanner crash while erroneously trying to resolve non necessary dependencies
> -------------------------------------------------------------------------------
>
> Key: DROOLS-754
> URL: https://issues.jboss.org/browse/DROOLS-754
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.2.0.Final
> Environment: kie-ci
> Reporter: Matteo Mortari
> Assignee: Mario Fusco
> Priority: Minor
> Attachments: 20150331.DROOLS-754.zip
>
>
> h5. Overview
> Given kie.maven.settings.custom to force KIE libraries to reference only an internal nexus repo without Maven-central proxy just for the kjar of the rules.
> Given a KieContainer created with ReleaseId, trying to create a KieScanner would fail if the kjar of the release ID contain parametrized versions in the POM, because the KiScanner does not substitute the parameter, and moreover it tries to resolve them anyway even if those dependencies are not actually needed because having scope=test.
> Even changing the internal nexus repo, althought may not be feasible, for Maven-central proxy (http://repo1.maven.org/maven2/) would fail in resolving other dependencies.
> *keypoint*: have a way to instruct KIE KieContainer AND KieScanner, to reference just-and-only an internal Nexus repo just and only for the KJar for the rules, without having to internally proxy or double-check Maven central, please?
> Could you kindly advise accordingly, please?
> h5. Details
> Given a kjar artifact named {{kiescanner-testandversionissue-rules}} with the following pom (extract):
> {code:xml}
> <properties>
> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
> <drools-version>6.2.0.Final</drools-version>
> <slf4j-version>1.7.2</slf4j-version>
> <junit-version>4.11</junit-version>
> </properties>
>
> <dependencyManagement>
> <dependencies>
> <dependency>
> <groupId>org.drools</groupId>
> <artifactId>drools-bom</artifactId>
> <type>pom</type>
> <version>${drools-version}</version>
> <scope>import</scope>
> </dependency>
> </dependencies>
> </dependencyManagement>
> <dependencies>
>
> <dependency>
> <groupId>org.drools</groupId>
> <artifactId>drools-compiler</artifactId>
> <scope>test</scope>
> </dependency>
> <dependency>
> <groupId>junit</groupId>
> <artifactId>junit</artifactId>
> <version>${junit-version}</version>
> <scope>test</scope>
> </dependency>
> <dependency>
> <groupId>org.slf4j</groupId>
> <artifactId>slf4j-log4j12</artifactId>
> <version>${slf4j-version}</version>
> <scope>test</scope>
> </dependency>
> </dependencies>
> {code}
> Please notice the dependencies are parametrized in the versions, and moreover are not really required for runtime because scope=test.
> Now assume this kjar is deployed to a maven repo, like a nexus repository.
> Now given a client application havign kie.maven.settings.custom to force KIE libraries to reference only an internal nexus repo:
> {code}
> ReleaseId rId = kieServices.newReleaseId( "com.acme", "kiescanner-testandversionissue-rules", "RELEASE" );
> KieContainer kieContainer = kieServices.newKieContainer( rId );
> LOG.info("kieContainer exists. {}", kieContainer);
> LOG.info("Now about to create kieScanner...");
> KieScanner kScanner = kieServices.newKieScanner( kieContainer );
> kScanner.start( KIE_SCANNER_INTERVAL );
> {code}
> This code will fail with the following in the log (extract):
> {code}
> INFO [com.acme.kiescanner_testandversionissue_client.App] (main) kieContainer exists. org.drools.compiler.kie.builder.impl.KieContainerImpl@1229a2b7
> INFO [com.acme.kiescanner_testandversionissue_client.App] (main) Now about to create kieScanner...
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Sending request: GET /nexus/content/groups/public/org/slf4j/slf4j-log4j12/$%7Bslf4j-version%7D/slf4j-log4j12-$%7Bslf4j-version%7D.pom HTTP/1.1
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Receiving response: HTTP/1.1 404 Not Found
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Connection 0.0.0.0:56971<->127.0.0.1:8081 closed
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Connection 0.0.0.0:56971<->127.0.0.1:8081 closed
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Sending request: GET /nexus/content/groups/public/junit/junit/$%7Bjunit-version%7D/junit-$%7Bjunit-version%7D.pom HTTP/1.1
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Receiving response: HTTP/1.1 404 Not Found
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Connection 0.0.0.0:56972<->127.0.0.1:8081 closed
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Connection 0.0.0.0:56972<->127.0.0.1:8081 closed
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Sending request: GET /nexus/content/groups/public/org/drools/drools-bom/$%7Bdrools-version%7D/drools-bom-$%7Bdrools-version%7D.pom HTTP/1.1
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Receiving response: HTTP/1.1 404 Not Found
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Connection 0.0.0.0:56973<->127.0.0.1:8081 closed
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Connection 0.0.0.0:56973<->127.0.0.1:8081 closed
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Sending request: GET /nexus/content/groups/public/org/slf4j/slf4j-log4j12/$%7Bslf4j-version%7D/slf4j-log4j12-$%7Bslf4j-version%7D.jar HTTP/1.1
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Receiving response: HTTP/1.1 404 Not Found
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Connection 0.0.0.0:56974<->127.0.0.1:8081 closed
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Connection 0.0.0.0:56974<->127.0.0.1:8081 closed
> WARN [org.kie.scanner.MavenRepository] (main) Unable to resolve artifact: org.slf4j:slf4j-log4j12:${slf4j-version}
> {code}
> We can notice two issues:
> * the ${...-version} is not substitued while trying to resolve these artifacts on the nexus repo, the URL contains the ${...-version} literally
> * actually why the KieScanner try to resolve them given the dependencies are scope=test ?
> Also, even changing the internal nexus repo for Maven-central proxy (http://repo1.maven.org/maven2/) by:
> nexus connect with default user admin/admin123, add proxy repo http://repo1.maven.org/maven2/), go to group "public" and add the proxy, erase local-user .m2 drools-bom to force re-resolution,
> And re-running the client application again, would instead crash in resolving the following:
> {code}
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Sending request: HEAD /nexus/content/groups/public/org/jboss/dashboard-builder/dashboard-builder-bom/6.2.0.Final/dashboard-builder-bom-6.2.0.Final.pom HTTP/1.1
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Receiving response: HTTP/1.1 404 Not Found
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Connection 0.0.0.0:57598<->127.0.0.1:8081 closed
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Connection 0.0.0.0:57598<->127.0.0.1:8081 closed
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Sending request: HEAD /nexus/content/groups/public/org/dashbuilder/dashbuilder-bom/0.2.1.Final/dashbuilder-bom-0.2.1.Final.pom HTTP/1.1
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Receiving response: HTTP/1.1 404 Not Found
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Connection 0.0.0.0:57599<->127.0.0.1:8081 closed
> DEBUG [org.apache.http.impl.conn.DefaultClientConnection] (main) Connection 0.0.0.0:57599<->127.0.0.1:8081 closed
> {code}
> Could you kindly advise accordingly, please?
> h5. Conclusion
> Have a way to instruct KIE KieContainer AND KieScanner, to reference just-and-only an internal Nexus repo just and only for the KJar for the rules, without having to proxy Maven central
> Please notice:
> IFF in the custom kie-settings.xml I do remove the mirror definition, the problem WILL be that KIE libraries will try to resolve the {{kiescanner-testandversionissue-rules}} kjar in *both* Maven central and the local repo, and this is not advisable as the rule package name should go straight and just to the internal maven repo.
> h5. Steps to reproduce
> I will attach reproducer containing
> * kiescanner-testandversionissue-rules
> * kiescanner-testandversionissue-client
> * standalone nexus containing just and only repo for the kjar rules without any Maven-central proxy
> you can use the last for standalone test, otherwise you can deploy the rule and reference to another disposable internal Nexus repo by also updating the custom kie-settings.xml in the client app.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years