[Red Hat JIRA] (WFLY-13969) signature test failures
by Scott Marlow (Jira)
[ https://issues.redhat.com/browse/WFLY-13969?page=com.atlassian.jira.plugi... ]
Scott Marlow updated WFLY-13969:
--------------------------------
Summary: signature test failures (was: EE 9 Transformation needs to remove some abstract keyword from WebSocket SPEC API)
> signature test failures
> -----------------------
>
> Key: WFLY-13969
> URL: https://issues.redhat.com/browse/WFLY-13969
> Project: WildFly
> Issue Type: Sub-task
> Components: EE
> Reporter: Scott Marlow
> Priority: Major
>
> We need to remove the abstract keyword from some WebSocket API methods to address signature test failures:
>
> {quote}
> javatest.batch] Missing Methods
> [javatest.batch] ---------------
> [javatest.batch]
> [javatest.batch] jakarta.websocket.Decoder: method public void jakarta.websocket.Decoder.destroy()
> [javatest.batch] --- affected jakarta.websocket.Decoder$TextStream,jakarta.websocket.Decoder$Text,jakarta.websocket.Decoder$BinaryStream,jakarta.websocket.Decoder$Binary
> [javatest.batch] jakarta.websocket.Decoder: method public void jakarta.websocket.Decoder.init(jakarta.websocket.EndpointConfig)
> [javatest.batch] --- affected jakarta.websocket.Decoder$TextStream,jakarta.websocket.Decoder$Text,jakarta.websocket.Decoder$BinaryStream,jakarta.websocket.Decoder$Binary
> [javatest.batch] jakarta.websocket.Encoder: method public void jakarta.websocket.Encoder.destroy()
> [javatest.batch] --- affected jakarta.websocket.Encoder$TextStream,jakarta.websocket.Encoder$Text,jakarta.websocket.Encoder$BinaryStream,jakarta.websocket.Encoder$Binary
> [javatest.batch] jakarta.websocket.Encoder: method public void jakarta.websocket.Encoder.init(jakarta.websocket.EndpointConfig)
> [javatest.batch] --- affected jakarta.websocket.Encoder$TextStream,jakarta.websocket.Encoder$Text,jakarta.websocket.Encoder$BinaryStream,jakarta.websocket.Encoder$Binary
> [javatest.batch]
> [javatest.batch] Added Methods
> [javatest.batch] -------------
> [javatest.batch]
> [javatest.batch] jakarta.websocket.Decoder: method public abstract void jakarta.websocket.Decoder.destroy()
> [javatest.batch] --- affected jakarta.websocket.Decoder$TextStream,jakarta.websocket.Decoder$Text,jakarta.websocket.Decoder$BinaryStream,jakarta.websocket.Decoder$Binary
> [javatest.batch] jakarta.websocket.Decoder: method public abstract void jakarta.websocket.Decoder.init(jakarta.websocket.EndpointConfig)
> [javatest.batch] --- affected jakarta.websocket.Decoder$TextStream,jakarta.websocket.Decoder$Text,jakarta.websocket.Decoder$BinaryStream,jakarta.websocket.Decoder$Binary
> [javatest.batch] jakarta.websocket.Encoder: method public abstract void jakarta.websocket.Encoder.destroy()
> [javatest.batch] --- affected jakarta.websocket.Encoder$TextStream,jakarta.websocket.Encoder$Text,jakarta.websocket.Encoder$BinaryStream,jakarta.websocket.Encoder$Binary
> [javatest.batch] jakarta.websocket.Encoder: method public abstract void jakarta.websocket.Encoder.init(jakarta.websocket.EndpointConfig)
> [javatest.batch] --- affected jakarta.websocket.Encoder$TextStream,jakarta.websocket.Encoder$Text,jakarta.websocket.Encoder$BinaryStream,jakarta.websocket.Encoder$Binary
> [javatest.batch]
> {quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[Red Hat JIRA] (WFLY-13969) EE 9 Transformation needs to remove some abstract keyword from WebSocket SPEC API
by Scott Marlow (Jira)
[ https://issues.redhat.com/browse/WFLY-13969?page=com.atlassian.jira.plugi... ]
Scott Marlow reassigned WFLY-13969:
-----------------------------------
Assignee: (was: Brian Stansberry)
> EE 9 Transformation needs to remove some abstract keyword from WebSocket SPEC API
> ---------------------------------------------------------------------------------
>
> Key: WFLY-13969
> URL: https://issues.redhat.com/browse/WFLY-13969
> Project: WildFly
> Issue Type: Sub-task
> Components: EE
> Reporter: Scott Marlow
> Priority: Major
>
> We need to remove the abstract keyword from some WebSocket API methods to address signature test failures:
>
> {quote}
> javatest.batch] Missing Methods
> [javatest.batch] ---------------
> [javatest.batch]
> [javatest.batch] jakarta.websocket.Decoder: method public void jakarta.websocket.Decoder.destroy()
> [javatest.batch] --- affected jakarta.websocket.Decoder$TextStream,jakarta.websocket.Decoder$Text,jakarta.websocket.Decoder$BinaryStream,jakarta.websocket.Decoder$Binary
> [javatest.batch] jakarta.websocket.Decoder: method public void jakarta.websocket.Decoder.init(jakarta.websocket.EndpointConfig)
> [javatest.batch] --- affected jakarta.websocket.Decoder$TextStream,jakarta.websocket.Decoder$Text,jakarta.websocket.Decoder$BinaryStream,jakarta.websocket.Decoder$Binary
> [javatest.batch] jakarta.websocket.Encoder: method public void jakarta.websocket.Encoder.destroy()
> [javatest.batch] --- affected jakarta.websocket.Encoder$TextStream,jakarta.websocket.Encoder$Text,jakarta.websocket.Encoder$BinaryStream,jakarta.websocket.Encoder$Binary
> [javatest.batch] jakarta.websocket.Encoder: method public void jakarta.websocket.Encoder.init(jakarta.websocket.EndpointConfig)
> [javatest.batch] --- affected jakarta.websocket.Encoder$TextStream,jakarta.websocket.Encoder$Text,jakarta.websocket.Encoder$BinaryStream,jakarta.websocket.Encoder$Binary
> [javatest.batch]
> [javatest.batch] Added Methods
> [javatest.batch] -------------
> [javatest.batch]
> [javatest.batch] jakarta.websocket.Decoder: method public abstract void jakarta.websocket.Decoder.destroy()
> [javatest.batch] --- affected jakarta.websocket.Decoder$TextStream,jakarta.websocket.Decoder$Text,jakarta.websocket.Decoder$BinaryStream,jakarta.websocket.Decoder$Binary
> [javatest.batch] jakarta.websocket.Decoder: method public abstract void jakarta.websocket.Decoder.init(jakarta.websocket.EndpointConfig)
> [javatest.batch] --- affected jakarta.websocket.Decoder$TextStream,jakarta.websocket.Decoder$Text,jakarta.websocket.Decoder$BinaryStream,jakarta.websocket.Decoder$Binary
> [javatest.batch] jakarta.websocket.Encoder: method public abstract void jakarta.websocket.Encoder.destroy()
> [javatest.batch] --- affected jakarta.websocket.Encoder$TextStream,jakarta.websocket.Encoder$Text,jakarta.websocket.Encoder$BinaryStream,jakarta.websocket.Encoder$Binary
> [javatest.batch] jakarta.websocket.Encoder: method public abstract void jakarta.websocket.Encoder.init(jakarta.websocket.EndpointConfig)
> [javatest.batch] --- affected jakarta.websocket.Encoder$TextStream,jakarta.websocket.Encoder$Text,jakarta.websocket.Encoder$BinaryStream,jakarta.websocket.Encoder$Binary
> [javatest.batch]
> {quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[Red Hat JIRA] (WFLY-13969) EE 9 Transformation needs to remove some abstract keyword from WebSocket SPEC API
by Scott Marlow (Jira)
Scott Marlow created WFLY-13969:
-----------------------------------
Summary: EE 9 Transformation needs to remove some abstract keyword from WebSocket SPEC API
Key: WFLY-13969
URL: https://issues.redhat.com/browse/WFLY-13969
Project: WildFly
Issue Type: Sub-task
Components: EE
Reporter: Scott Marlow
Assignee: Brian Stansberry
We need to remove the abstract keyword from some WebSocket API methods to address signature test failures:
{quote}
javatest.batch] Missing Methods
[javatest.batch] ---------------
[javatest.batch]
[javatest.batch] jakarta.websocket.Decoder: method public void jakarta.websocket.Decoder.destroy()
[javatest.batch] --- affected jakarta.websocket.Decoder$TextStream,jakarta.websocket.Decoder$Text,jakarta.websocket.Decoder$BinaryStream,jakarta.websocket.Decoder$Binary
[javatest.batch] jakarta.websocket.Decoder: method public void jakarta.websocket.Decoder.init(jakarta.websocket.EndpointConfig)
[javatest.batch] --- affected jakarta.websocket.Decoder$TextStream,jakarta.websocket.Decoder$Text,jakarta.websocket.Decoder$BinaryStream,jakarta.websocket.Decoder$Binary
[javatest.batch] jakarta.websocket.Encoder: method public void jakarta.websocket.Encoder.destroy()
[javatest.batch] --- affected jakarta.websocket.Encoder$TextStream,jakarta.websocket.Encoder$Text,jakarta.websocket.Encoder$BinaryStream,jakarta.websocket.Encoder$Binary
[javatest.batch] jakarta.websocket.Encoder: method public void jakarta.websocket.Encoder.init(jakarta.websocket.EndpointConfig)
[javatest.batch] --- affected jakarta.websocket.Encoder$TextStream,jakarta.websocket.Encoder$Text,jakarta.websocket.Encoder$BinaryStream,jakarta.websocket.Encoder$Binary
[javatest.batch]
[javatest.batch] Added Methods
[javatest.batch] -------------
[javatest.batch]
[javatest.batch] jakarta.websocket.Decoder: method public abstract void jakarta.websocket.Decoder.destroy()
[javatest.batch] --- affected jakarta.websocket.Decoder$TextStream,jakarta.websocket.Decoder$Text,jakarta.websocket.Decoder$BinaryStream,jakarta.websocket.Decoder$Binary
[javatest.batch] jakarta.websocket.Decoder: method public abstract void jakarta.websocket.Decoder.init(jakarta.websocket.EndpointConfig)
[javatest.batch] --- affected jakarta.websocket.Decoder$TextStream,jakarta.websocket.Decoder$Text,jakarta.websocket.Decoder$BinaryStream,jakarta.websocket.Decoder$Binary
[javatest.batch] jakarta.websocket.Encoder: method public abstract void jakarta.websocket.Encoder.destroy()
[javatest.batch] --- affected jakarta.websocket.Encoder$TextStream,jakarta.websocket.Encoder$Text,jakarta.websocket.Encoder$BinaryStream,jakarta.websocket.Encoder$Binary
[javatest.batch] jakarta.websocket.Encoder: method public abstract void jakarta.websocket.Encoder.init(jakarta.websocket.EndpointConfig)
[javatest.batch] --- affected jakarta.websocket.Encoder$TextStream,jakarta.websocket.Encoder$Text,jakarta.websocket.Encoder$BinaryStream,jakarta.websocket.Encoder$Binary
[javatest.batch]
{quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[Red Hat JIRA] (DROOLS-5697) Make exec model's groupBy() composable
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-5697?page=com.atlassian.jira.plug... ]
Mario Fusco updated DROOLS-5697:
--------------------------------
Sprint: 2020 Week 40-42 (from Sep 28) (was: 2020 Week 43-45 (from Okt 19))
> Make exec model's groupBy() composable
> --------------------------------------
>
> Key: DROOLS-5697
> URL: https://issues.redhat.com/browse/DROOLS-5697
> Project: Drools
> Issue Type: Enhancement
> Components: executable model
> Affects Versions: 7.44.0.Final
> Reporter: Lukáš Petrovický
> Assignee: Mario Fusco
> Priority: Major
>
> In some of the OptaPlanner examples, we have Constraint Streams like this:
> {code:java}
> .groupBy(ProcessAssignment::getService, count())
> .groupBy(Service::getTag, max((service, count) -> count))
> {code}
> This will:
> - Take all ProcessAssigment instances.
> - Count all such instances which run on the same Service.
> - Out of all the pairs of (service, count) find the maximum count where the services share the same Tag.
> This is an example of groupBy composition. Currently, we implement it with the old, inefficient groupBy. That implementation looks something like this:
> {noformat}
> when
> $tuples: List<Tuple<Service, Integer>> from accumulate(
> $p: ProcessAssignment(),
> ...
> groupBy(ProcessAssignment::getService, count())
> )
> $tuples2: List<Tuple<String, Integer>> from accumulate(
> $tuple: Tuple<Service, Integer> from $tuples,
> ...
> groupBy(Service::getTag, max($tuple._2))
> )
> $result: Tuple<String, Integer> from $tuples2
> then
> System.out.println($result);
> end
> {noformat}
> We'd like the new groupBy construct to be capable of composition instead.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[Red Hat JIRA] (DROOLS-5697) Make exec model's groupBy() composable
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-5697?page=com.atlassian.jira.plug... ]
Mario Fusco updated DROOLS-5697:
--------------------------------
Sprint: 2020 Week 43-45 (from Okt 19) (was: 2020 Week 40-42 (from Sep 28))
> Make exec model's groupBy() composable
> --------------------------------------
>
> Key: DROOLS-5697
> URL: https://issues.redhat.com/browse/DROOLS-5697
> Project: Drools
> Issue Type: Enhancement
> Components: executable model
> Affects Versions: 7.44.0.Final
> Reporter: Lukáš Petrovický
> Assignee: Mario Fusco
> Priority: Major
>
> In some of the OptaPlanner examples, we have Constraint Streams like this:
> {code:java}
> .groupBy(ProcessAssignment::getService, count())
> .groupBy(Service::getTag, max((service, count) -> count))
> {code}
> This will:
> - Take all ProcessAssigment instances.
> - Count all such instances which run on the same Service.
> - Out of all the pairs of (service, count) find the maximum count where the services share the same Tag.
> This is an example of groupBy composition. Currently, we implement it with the old, inefficient groupBy. That implementation looks something like this:
> {noformat}
> when
> $tuples: List<Tuple<Service, Integer>> from accumulate(
> $p: ProcessAssignment(),
> ...
> groupBy(ProcessAssignment::getService, count())
> )
> $tuples2: List<Tuple<String, Integer>> from accumulate(
> $tuple: Tuple<Service, Integer> from $tuples,
> ...
> groupBy(Service::getTag, max($tuple._2))
> )
> $result: Tuple<String, Integer> from $tuples2
> then
> System.out.println($result);
> end
> {noformat}
> We'd like the new groupBy construct to be capable of composition instead.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months
[Red Hat JIRA] (WFLY-13949) JNDI lookup for JMS Queue failing
by Emmanuel Hugonnet (Jira)
[ https://issues.redhat.com/browse/WFLY-13949?page=com.atlassian.jira.plugi... ]
Emmanuel Hugonnet resolved WFLY-13949.
--------------------------------------
Resolution: Not a Bug
https://github.com/wildfly/wildfly/blob/master/naming/src/main/java/org/j... explains exactly why the leading '/' creates this issue.
> JNDI lookup for JMS Queue failing
> ---------------------------------
>
> Key: WFLY-13949
> URL: https://issues.redhat.com/browse/WFLY-13949
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 20.0.1.Final
> Reporter: Francis Griffin
> Assignee: Emmanuel Hugonnet
> Priority: Major
> Attachments: dpsrTest.tgz
>
>
> I have a JMS app which has been running successfully under WF10 for some years. I'm trying to migrate to WF20, but getting an error trying to look up the JMS Queue. The JDK is OpenJDK 11.
> I've tried to make the reproducible case as simple as possible. The server is unpacked from the downloaded tar.gz, and is not modified except to add a guest user for JMS (which is not needed for the reproducible case, since we never actually create a Connection). The queue is the DLQ queue defined in the distribution.
> The error is a NameNotFoundException:
> Exception in thread "main" javax.naming.NameNotFoundException: jms/queue -- service jboss.naming.context.java.jboss.exported.jms.queue
> at org.jboss.as.naming@20.0.1.Final//org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:106)
> at org.jboss.as.naming@20.0.1.Final//org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207)
> at org.jboss.as.naming@20.0.1.Final//org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
> at org.jboss.as.naming@20.0.1.Final//org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
> at org.wildfly.naming-client@1.0.13.Final//org.wildfly.naming.client.remote.RemoteServerTransport.handleLookup(RemoteServerTransport.java:203)
> at org.wildfly.naming-client@1.0.13.Final//org.wildfly.naming.client.remote.RemoteServerTransport$1.handleMessage(RemoteServerTransport.java:123)
> at org.jboss.remoting@5.0.18.Final//org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:430)
> at org.jboss.remoting@5.0.18.Final//org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:991)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.base/java.lang.Thread.run(Thread.java:834)
> No matter what queue name I use, the lookup is failing on the string jms/queue rather than the expected jms/queue/DLQ.
> I fully expect that this is some stupid error on my part, something I'm looking at and just not seeing, because I know of others (albeit using Windows) who are using 20.0.1.Final for the full app without issue. But I can't for the life of me see what it is.
> Tha actual full application looks up a ConnectionFactory of "jms/RemoteConnectionFactory" and creates Connections and Sessions before looking up the Queue name. The lookup for the factory name works perfectly, as does the other stuff, but the lookup for the Queue name gets the same NameNotFoundException shown above.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 9 months