[JBoss JIRA] (DROOLS-5362) Dependencies not necessarily loaded
by Steve Davidson (Jira)
Steve Davidson created DROOLS-5362:
--------------------------------------
Summary: Dependencies not necessarily loaded
Key: DROOLS-5362
URL: https://issues.redhat.com/browse/DROOLS-5362
Project: Drools
Issue Type: Bug
Components: kie server
Affects Versions: 7.29.0.Final
Reporter: Steve Davidson
Assignee: Mario Fusco
Attachments: KieDependencyDemo.tbz
When a Rule has a dependency on a class imported from a library jar in the local repository, the rule fails to compile/load:
{code}
May 22, 2020 3:35:05 PM org.drools.compiler.kie.builder.impl.AbstractKieProject buildKnowledgePackages
SEVERE: Unable to build KieBaseModel:default-dependency-demo
Unable to resolve ObjectType 'DemoData' : [Rule name='Inventory Item 001']
Unable to resolve ObjectType 'DemoData' : [Rule name='Inventory Item 002']
Rule Compilation error : [Rule name='Inventory Item 001']
com/j2eeguys/demo/rules/Rule_Inventory_Item_0012002200180.java (2:40) : Only a type can be imported. com.j2eeguys.demo.data.DemoData resolves to a package
com/j2eeguys/demo/rules/Rule_Inventory_Item_0012002200180.java (8:490) : jds cannot be resolved
com/j2eeguys/demo/rules/Rule_Inventory_Item_0012002200180.java (9:543) : jds cannot be resolved
Rule Compilation error : [Rule name='Inventory Item 002']
com/j2eeguys/demo/rules/Rule_Inventory_Item_0021364978446.java (2:40) : Only a type can be imported. com.j2eeguys.demo.data.DemoData resolves to a package
com/j2eeguys/demo/rules/Rule_Inventory_Item_0021364978446.java (8:490) : jds cannot be resolved
com/j2eeguys/demo/rules/Rule_Inventory_Item_0021364978446.java (9:543) : jds cannot be resolved
Error importing : 'com.j2eeguys.demo.data.DemoData'
May 22, 2020 3:35:05 PM org.kie.server.services.impl.KieServerImpl createContainer
SEVERE: Error creating container 'Kie Dependency Demo: kie-server' for module 'com.j2eeguys.demo:demo-dependency-rules:0.1.0-SNAPSHOT'
java.lang.RuntimeException: Error while creating KieBase[Message [id=1, kieBase=default-dependency-demo, level=ERROR, path=com/j2eeguys/demo/rules/kieIssueDemo.drl, line=7, column=0
text=Unable to resolve ObjectType 'DemoData'], Message [id=2, kieBase=default-dependency-demo, level=ERROR, path=com/j2eeguys/demo/rules/kieIssueDemo.drl, line=16, column=0
text=Unable to resolve ObjectType 'DemoData'], Message [id=3, kieBase=default-dependency-demo, level=ERROR, path=com/j2eeguys/demo/rules/kieIssueDemo.drl, line=5, column=0
text=Rule Compilation error Only a type can be imported. com.j2eeguys.demo.data.DemoData resolves to a package
jds cannot be resolved
jds cannot be resolved], Message [id=4, kieBase=default-dependency-demo, level=ERROR, path=com/j2eeguys/demo/rules/kieIssueDemo.drl, line=14, column=0
text=Rule Compilation error Only a type can be imported. com.j2eeguys.demo.data.DemoData resolves to a package
jds cannot be resolved
jds cannot be resolved], Message [id=5, kieBase=default-dependency-demo, level=ERROR, path=com/j2eeguys/demo/rules/kieIssueDemo.drl, line=1, column=0
text=Error importing : 'com.j2eeguys.demo.data.DemoData']]
at org.drools.compiler.kie.builder.impl.KieContainerImpl.getKieBase(KieContainerImpl.java:379)
at org.kie.server.services.drools.DroolsKieServerExtension.createContainer(DroolsKieServerExtension.java:98)
at org.kie.server.services.impl.KieServerImpl.createContainer(KieServerImpl.java:286)
at org.kie.server.remote.rest.common.resource.KieServerRestImpl.createContainer(KieServerRestImpl.java:157)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:140)
at org.jboss.resteasy.core.ResourceMethodInvoker.internalInvokeOnTarget(ResourceMethodInvoker.java:509)
at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTargetAfterFilter(ResourceMethodInvoker.java:399)
at org.jboss.resteasy.core.ResourceMethodInvoker.lambda$invokeOnTarget$0(ResourceMethodInvoker.java:363)
at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:358)
at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:365)
at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:337)
at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:310)
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:443)
at org.jboss.resteasy.core.SynchronousDispatcher.lambda$invoke$4(SynchronousDispatcher.java:233)
at org.jboss.resteasy.core.SynchronousDispatcher.lambda$preprocess$0(SynchronousDispatcher.java:139)
at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:358)
at org.jboss.resteasy.core.SynchronousDispatcher.preprocess(SynchronousDispatcher.java:142)
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:219)
at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:227)
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at org.eclipse.jetty.servlet.ServletHolder$NotAsyncServlet.service(ServletHolder.java:1401)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:760)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1617)
at org.eclipse.jetty.websocket.server.WebSocketUpgradeFilter.doFilter(WebSocketUpgradeFilter.java:226)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1604)
at org.kie.server.services.impl.security.web.CaptureHttpRequestFilter.doFilter(CaptureHttpRequestFilter.java:42)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1596)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:501)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1592)
at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1296)
at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1562)
at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1211)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:221)
at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
at org.eclipse.jetty.server.Server.handle(Server.java:500)
at org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:386)
at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:562)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:378)
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:270)
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336)
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313)
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171)
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:129)
at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:388)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:806)
at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:938)
at java.base/java.lang.Thread.run(Thread.java:834)
{code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (ELY-1971) Bad designed wildlfy-elytron jar, shaded jar with dependencies
by Marek Novotny (Jira)
[ https://issues.redhat.com/browse/ELY-1971?page=com.atlassian.jira.plugin.... ]
Marek Novotny commented on ELY-1971:
------------------------------------
and there is one hiccup in shaded, there is excluded wildfly-commons dependency so the wildcard exclusion will have possible issue with missing the wildfly-commons too.
> Bad designed wildlfy-elytron jar, shaded jar with dependencies
> --------------------------------------------------------------
>
> Key: ELY-1971
> URL: https://issues.redhat.com/browse/ELY-1971
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Marek Novotny
> Assignee: Darran Lofthouse
> Priority: Major
>
> Wildfly-elytron jar is shaded with all wildfly elytron modules + jboss-logging, but it keeps the shaded classes in jar in its dependency chain which makes duplicated classes in dependency tree when using the wildfly-elytron in maven project.
> Avoiding duplicates would effectively need to add exclusion dependency to wildfly-elytron like:
> {noformat}
> <dependency>
> <groupId>org.wildlfy.security</groupId>
> <artifactId>wildfly-elytron</artifactId>
> <version>some-version</version>
> <exclusions>
> <exclusion>
> <groupId>*</groupId>
> <artifactId>*</artifactId>
> </exclusion>
> </exclusions>
> </dependency>
> {noformat}
> which is just a hack for bad designed artifact IMHO.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (ELY-1971) Bad designed wildlfy-elytron jar, shaded jar with dependencies
by Marek Novotny (Jira)
Marek Novotny created ELY-1971:
----------------------------------
Summary: Bad designed wildlfy-elytron jar, shaded jar with dependencies
Key: ELY-1971
URL: https://issues.redhat.com/browse/ELY-1971
Project: WildFly Elytron
Issue Type: Bug
Reporter: Marek Novotny
Assignee: Darran Lofthouse
Wildfly-elytron jar is shaded with all wildfly elytron modules + jboss-logging, but it keeps the shaded classes in jar in its dependency chain which makes duplicated classes in dependency tree when using the wildfly-elytron in maven project.
Avoiding duplicates would effectively need to add exclusion dependency to wildfly-elytron like:
{noformat}
<dependency>
<groupId>org.wildlfy.security</groupId>
<artifactId>wildfly-elytron</artifactId>
<version>some-version</version>
<exclusions>
<exclusion>
<groupId>*</groupId>
<artifactId>*</artifactId>
</exclusion>
</exclusions>
</dependency>
{noformat}
which is just a hack for bad designed artifact IMHO.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (ELY-1971) Bad designed wildlfy-elytron jar, shaded jar with dependencies
by Marek Novotny (Jira)
[ https://issues.redhat.com/browse/ELY-1971?page=com.atlassian.jira.plugin.... ]
Marek Novotny updated ELY-1971:
-------------------------------
Priority: Major (was: Critical)
> Bad designed wildlfy-elytron jar, shaded jar with dependencies
> --------------------------------------------------------------
>
> Key: ELY-1971
> URL: https://issues.redhat.com/browse/ELY-1971
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Marek Novotny
> Assignee: Darran Lofthouse
> Priority: Major
>
> Wildfly-elytron jar is shaded with all wildfly elytron modules + jboss-logging, but it keeps the shaded classes in jar in its dependency chain which makes duplicated classes in dependency tree when using the wildfly-elytron in maven project.
> Avoiding duplicates would effectively need to add exclusion dependency to wildfly-elytron like:
> {noformat}
> <dependency>
> <groupId>org.wildlfy.security</groupId>
> <artifactId>wildfly-elytron</artifactId>
> <version>some-version</version>
> <exclusions>
> <exclusion>
> <groupId>*</groupId>
> <artifactId>*</artifactId>
> </exclusion>
> </exclusions>
> </dependency>
> {noformat}
> which is just a hack for bad designed artifact IMHO.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-13508) Incorrect layer name for 'naming' layer on the ayer specification file
by Yeray Borges Santana (Jira)
Yeray Borges Santana created WFLY-13508:
-------------------------------------------
Summary: Incorrect layer name for 'naming' layer on the ayer specification file
Key: WFLY-13508
URL: https://issues.redhat.com/browse/WFLY-13508
Project: WildFly
Issue Type: Bug
Reporter: Yeray Borges Santana
Assignee: Yeray Borges Santana
Galleon layer name for "naming" layer should be "naming" instead of "ee".
This is not a problem at all since currently layers names are discovered by the directory name it resides, however, the wrong name here could lead to confusion.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-13132) Wrong/Incomplete CLUSTER_TOPOLOGY update sent to EJB client
by Richard Achmatowicz (Jira)
[ https://issues.redhat.com/browse/WFLY-13132?page=com.atlassian.jira.plugi... ]
Richard Achmatowicz commented on WFLY-13132:
--------------------------------------------
The work for this issue is now basically done for upstream and the PR (in a private wildflyclustering repo) involves significant refactoring of the relationships between connectors, client mappings registries and the way in which cluster topology listeners are set up.
Essentially, for every connector,we have a separate ClusterTopologyRegistrar and set of client mappings entries. For an incoming connection, when an EJBServerChannel is created, its ClusterTopologyListener is registered with a ClusterTopologyRegistar based on the port of the Connection associated with the Channel and as a consequence, that connection will only receive client mappings relating to the connector it connected to. No need to change the client.
The issue requires one small change to EJB client library to add a getConnection() method to the ClusterTopologyListner interface and its implementation by EJBSefverChannel.
> Wrong/Incomplete CLUSTER_TOPOLOGY update sent to EJB client
> -----------------------------------------------------------
>
> Key: WFLY-13132
> URL: https://issues.redhat.com/browse/WFLY-13132
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 19.0.0.Beta2
> Reporter: Joerg Baesner
> Assignee: Richard Achmatowicz
> Priority: Major
> Labels: downstream_dependency
> Attachments: playground.zip
>
>
> h2. +Issue+
> h3. +General Client setup:+
> {code:java}
> Properties p = new Properties();
> p.put(Context.INITIAL_CONTEXT_FACTORY, "org.wildfly.naming.client.WildFlyInitialContextFactory");
> p.put(Context.PROVIDER_URL, {see below});
> p.put(Context.SECURITY_PRINCIPAL, USER);
> p.put(Context.SECURITY_CREDENTIALS, PWD);
> Context context = new InitialContext(p);
> {code}
> ----
> h3. +Standard server configuration:+
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:ejb3:5.0">
> ...
> <remote connector-ref="http-remoting-connector" thread-pool-name="default">
> <channel-creation-options>
> <option name="READ_TIMEOUT" value="${prop.remoting-connector.read.timeout:20}" type="xnio"/>
> <option name="MAX_OUTBOUND_MESSAGES" value="1234" type="remoting"/>
> </channel-creation-options>
> </remote>
> ...
> </subsystem>
> ...
> <subsystem xmlns="urn:jboss:domain:remoting:4.0">
> <connector name="remoting-connector" socket-binding="remoting" security-realm="ApplicationRealm">
> <properties>
> <property name="SSL_ENABLED" value="false"/>
> </properties>
> </connector>
> <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm"/>
> </subsystem>
> {code}
> h5. +invocation from remote client to server with:+
> * {{remote://localhost:4447}}
> * {{remote+http://localhost:8080}}
> h5. +Client side topology update always:+
> {noformat}
> DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message from node master:app-cluster-node0, registering cluster ejb to node master:app-cluster-node0
> DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message block from master:app-cluster-node0, registering block ::/0 to address 127.0.0.1:8080
> DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message from node master:app-cluster-node0, registering cluster ejb to node master:app-cluster-node1
> DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message block from master:app-cluster-node0, registering block ::/0 to address 127.0.0.1:8180
> DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_AVAILABLE(8) message from node master:app-cluster-node0 for module playground-app/playground-app-web
> DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_AVAILABLE(8) message from node master:app-cluster-node0 for module playground-app/playground-app-ejb
> {noformat}
> ----
> h3. +Legacy server configuration:+
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:ejb3:5.0">
> ...
> <remote connector-ref="remoting-connector" thread-pool-name="default">
> <channel-creation-options>
> <option name="READ_TIMEOUT" value="${prop.remoting-connector.read.timeout:20}" type="xnio"/>
> <option name="MAX_OUTBOUND_MESSAGES" value="1234" type="remoting"/>
> </channel-creation-options>
> </remote>
> ...
> </subsystem>
> ...
> <subsystem xmlns="urn:jboss:domain:remoting:4.0">
> <connector name="remoting-connector" socket-binding="remoting" security-realm="ApplicationRealm">
> <properties>
> <property name="SSL_ENABLED" value="false"/>
> </properties>
> </connector>
> <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm"/>
> </subsystem>
> {code}
> h5. +invocation from remote client to server with:+
> * {{remote://localhost:4447}}
> * {{remote+http://localhost:8080}}
> h5. +Client side topology update always:+
> {noformat}
> DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message from node master:app-cluster-node0, registering cluster ejb to node master:app-cluster-node0
> DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message block from master:app-cluster-node0, registering block ::/0 to address 127.0.0.1:4447
> DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message from node master:app-cluster-node0, registering cluster ejb to node master:app-cluster-node1
> DEBUG (XNIO-1 task-2) [org.jboss.ejb.client.invocation] Received CLUSTER_TOPOLOGY(15) message block from master:app-cluster-node0, registering block ::/0 to address 127.0.0.1:4547
> DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_AVAILABLE(8) message from node master:app-cluster-node0 for module playground-app/playground-app-web
> DEBUG (XNIO-1 task-1) [org.jboss.ejb.client.invocation] Received MODULE_AVAILABLE(8) message from node master:app-cluster-node0 for module playground-app/playground-app-ejb
> {noformat}
> h2. +Conclusion+
> Depending on what is configured as {{connector-ref}} in the {{remote}} of the _ejb3_ subsystem the {{CLUSTER_TOPOLOGY}} update is different. From a client perspective it would be expected that either the {{CLUSTER_TOPOLOGY}} update would _only_ contain destinations that are applicable for the _connector/protocol_ that has been used, or maybe even _ALL_ available destinations, as the client could potentially run a mix of protocols between invocations...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (ELY-1968) Update error message returned by AcmeClientSpi#getLocation
by Farah Juma (Jira)
[ https://issues.redhat.com/browse/ELY-1968?page=com.atlassian.jira.plugin.... ]
Farah Juma updated ELY-1968:
----------------------------
Fix Version/s: 1.12.0.CR4
> Update error message returned by AcmeClientSpi#getLocation
> ----------------------------------------------------------
>
> Key: ELY-1968
> URL: https://issues.redhat.com/browse/ELY-1968
> Project: WildFly Elytron
> Issue Type: Bug
> Components: API / SPI
> Reporter: Farah Juma
> Assignee: Sonia Zaldana
> Priority: Minor
> Fix For: 1.12.0.CR4
>
>
> The {{AcmeClientSpi#getLocation}} method returns the value of the "Location" header field if non-null. Otherwise, an exception is thrown. Currently, the error message is specific to accounts, i.e., the error message "No account location URL provided by ACME server" is returned. However, the {{AcmeClientSpi#getLocation}} method is actually called to retrieve the "Location" header field in other cases as well, like when obtaining the URL for orders and authorizations. This should be updated so that the exception that is thrown has an appropriate error message depending on the location URL that could not be retrieved (i.e., the error message should reference the "account location URL", the "order location URL", or the "authorization location URL" as appropriate).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (ELY-1968) Update error message returned by AcmeClientSpi#getLocation
by Farah Juma (Jira)
[ https://issues.redhat.com/browse/ELY-1968?page=com.atlassian.jira.plugin.... ]
Farah Juma resolved ELY-1968.
-----------------------------
Resolution: Done
> Update error message returned by AcmeClientSpi#getLocation
> ----------------------------------------------------------
>
> Key: ELY-1968
> URL: https://issues.redhat.com/browse/ELY-1968
> Project: WildFly Elytron
> Issue Type: Bug
> Components: API / SPI
> Reporter: Farah Juma
> Assignee: Sonia Zaldana
> Priority: Minor
> Fix For: 1.12.0.CR4
>
>
> The {{AcmeClientSpi#getLocation}} method returns the value of the "Location" header field if non-null. Otherwise, an exception is thrown. Currently, the error message is specific to accounts, i.e., the error message "No account location URL provided by ACME server" is returned. However, the {{AcmeClientSpi#getLocation}} method is actually called to retrieve the "Location" header field in other cases as well, like when obtaining the URL for orders and authorizations. This should be updated so that the exception that is thrown has an appropriate error message depending on the location URL that could not be retrieved (i.e., the error message should reference the "account location URL", the "order location URL", or the "authorization location URL" as appropriate).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month