March 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-3944) DMN Editor: Data type usability study

by Elizabeth Clayton (Jira)

[ https://issues.jboss.org/browse/DROOLS-3944?page=com.atlassian.jira.plugi... ] Elizabeth Clayton updated DROOLS-3944: -------------------------------------- Sprint: 2019 Week 23-25 > DMN Editor: Data type usability study > ------------------------------------- > > Key: DROOLS-3944 > URL: https://issues.jboss.org/browse/DROOLS-3944 > Project: Drools > Issue Type: Task > Components: DMN Editor > Environment: Version 7.4 > Reporter: Elizabeth Clayton > Assignee: Sarahjane Clark > Priority: Major > Labels: UX, UXTeam, Usability, drools-tools > > Lightweight usability study to test the ease of use in viewing, creating, editing and deleting data types, particularly structured data types. > GOALS: Access the Data Type editor in terms of productivity and usability. > * Ease of use when creating a complex type (concern: minimizing the mouse usage.) > * Ease of use when saving a basic data type (e.g. age: number) > * Discoverability of actions in the kebab menu, especially, insert nested, delete. > * Ease of use/accuracy: Type-ahead of the data type selector. -- This message was sent by Atlassian Jira (v7.12.1#712002)

3 months, 1 week

2
1
0 / 0

[JBoss JIRA] (WFLY-12461) Can't use smallrye-health without weld extension

by Florian Sailer (Jira)

Florian Sailer created WFLY-12461: ------------------------------------- Summary: Can't use smallrye-health without weld extension Key: WFLY-12461 URL: https://issues.jboss.org/browse/WFLY-12461 Project: WildFly Issue Type: Bug Components: MP Health Affects Versions: 17.0.1.Final Reporter: Florian Sailer Assignee: Jeff Mesnil Since this commit in the smallrye implementation it was possible to use smallrye without CDI. https://github.com/smallrye/smallrye-health/commit/a6a7812877d74d2c3f5b29... I'm trying to migrate from Wildfly 15.0.1-Final to 17.0.1-Final, where the smallrye-health extension unfortunately needs weld to startup. It's not possbible for me to activate weld on my sever, because there are some problems using the org.apache.cxf.jaxrs framework with weld. I am getting the following exception while starting: 14:16:04,960 ERROR [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0362: Capabilities required by resource '/subsystem=microprofile-health-smallrye' are not available: org.wildfly.weld; There are no known registration points which can provide this capability. -- This message was sent by Atlassian Jira (v7.13.5#713005)

1 year, 9 months

2
1
0 / 0

[JBoss JIRA] (WFLY-13183) WFLYWELD0041: WeldContainer is not started when redeploying

by Ranabir Chakraborty (Jira)

[ https://issues.redhat.com/browse/WFLY-13183?page=com.atlassian.jira.plugi... ] Ranabir Chakraborty commented on WFLY-13183: -------------------------------------------- [~baranowb] Can you please provide some details about this issue ? > WFLYWELD0041: WeldContainer is not started when redeploying > ----------------------------------------------------------- > > Key: WFLY-13183 > URL: https://issues.redhat.com/browse/WFLY-13183 > Project: WildFly > Issue Type: Bug > Reporter: Bartosz Baranowski > Assignee: Bartosz Baranowski > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11442) Remove unused dependencies from org.jboss.as.ejb3

by Ranabir Chakraborty (Jira)

[ https://issues.redhat.com/browse/WFLY-11442?page=com.atlassian.jira.plugi... ] Ranabir Chakraborty commented on WFLY-11442: -------------------------------------------- [~yersan] are you can I look into this issue ? > Remove unused dependencies from org.jboss.as.ejb3 > ------------------------------------------------- > > Key: WFLY-11442 > URL: https://issues.redhat.com/browse/WFLY-11442 > Project: WildFly > Issue Type: Bug > Components: Server > Reporter: Yeray Borges Santana > Assignee: Yeray Borges Santana > Priority: Major > > Initial analisys checking only first level dependencies from the resource exposed by {{org.jboss.as.ejb3}} shows that these dependencies are being unused: > * org.jboss.jts > * org.wildfly.security.elytron-web.undertow-server > * org.jboss.as.weld > * org.wildfly.clustering.marshalling.spi > * org.wildfly.clustering.marshalling.api > * org.wildfly.client.config > * org.hibernate > The task here is verify that they are not used by any other machanism besides of being a first level dependency. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (AG-134) Some issues in when use MSSQL SQLServerXADataSource

by Luis Barreiro (Jira)

[ https://issues.redhat.com/browse/AG-134?page=com.atlassian.jira.plugin.sy... ] Luis Barreiro resolved AG-134. ------------------------------ Fix Version/s: 1.8 Resolution: Done > Some issues in when use MSSQL SQLServerXADataSource > --------------------------------------------------- > > Key: AG-134 > URL: https://issues.redhat.com/browse/AG-134 > Project: Agroal > Issue Type: Enhancement > Components: pool > Affects Versions: 1.7 > Reporter: bingo chen > Assignee: Luis Barreiro > Priority: Major > Fix For: 1.8 > > > We use MSSQL as our data base server and use 'com.microsoft.sqlserver.jdbc.SQLServerXADataSource' as driver class. > Here some issues occured, the SQLServerXADataSource url property name is 'URL' not 'url', so we can't connect the data base server. > Environments: > 1.JDBC driver is 'mssql-jdbc.7.2.2.jre8' > <dependency> > <groupId>com.microsoft.sqlserver</groupId> > <artifactId>mssql-jdbc</artifactId> > <version>7.2.2.jre8</version> > </dependency> > 2.Agroal 1.7 > <dependency> > <groupId>io.agroal</groupId> > <artifactId>agroal-api</artifactId> > <version>1.7</version> > </dependency> > <dependency> > <groupId>io.agroal</groupId> > <artifactId>agroal-pool</artifactId> > <version>1.7</version> > </dependency> > <dependency> > <groupId>io.agroal</groupId> > <artifactId>agroal-narayana</artifactId> > <version>1.7</version> > </dependency> > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4897) Upgrade the wildfly-maven-plugin from 1.2.1.Final to 2.0.2.Final

by James Perkins (Jira)

James Perkins created WFCORE-4897: ------------------------------------- Summary: Upgrade the wildfly-maven-plugin from 1.2.1.Final to 2.0.2.Final Key: WFCORE-4897 URL: https://issues.redhat.com/browse/WFCORE-4897 Project: WildFly Core Issue Type: Component Upgrade Components: Build System Reporter: James Perkins Assignee: James Perkins Upgrade the {{org.wildfly.plugins:wildfly-maven-plugin}} from 1.2.1.Final to 2.0.2.Final. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13256) Upgrade bouncycastle to 1.65.0

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13256?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFLY-13256: ----------------------------------------- There was some discussion on the BC issue I filed that may be relevant. Or it could be completely irrelevant. https://github.com/bcgit/bc-java/issues/620#issuecomment-606339395 If it's relevant it would likely be something happening behind the scenes that we don't see since AIUI we're not seeing any stack traces in the logs. > Upgrade bouncycastle to 1.65.0 > ------------------------------ > > Key: WFLY-13256 > URL: https://issues.redhat.com/browse/WFLY-13256 > Project: WildFly > Issue Type: Component Upgrade > Components: Build System, Server > Reporter: Bartosz Spyrko > Assignee: Brian Stansberry > Priority: Blocker > Labels: downstream_dependency > Fix For: 20.0.0.Beta1 > > Attachments: handshake-error.log, handshake-success.log > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (AG-136) Add a safe callback interface for pool events

by Luis Barreiro (Jira)

[ https://issues.redhat.com/browse/AG-136?page=com.atlassian.jira.plugin.sy... ] Luis Barreiro resolved AG-136. ------------------------------ Resolution: Done > Add a safe callback interface for pool events > --------------------------------------------- > > Key: AG-136 > URL: https://issues.redhat.com/browse/AG-136 > Project: Agroal > Issue Type: Feature Request > Components: api, pool > Affects Versions: 1.7 > Reporter: Luis Barreiro > Assignee: Luis Barreiro > Priority: Major > Fix For: 1.8 > > > There is a need for a callback to intercept pool events that is safe for applications to use. > Right now the current listener interface is fine for container implementations, but should not be used by higher level applications because: > * The {{AgroalDataSourceListener}} interface was not designed with the Interceptor concept in mind. Agroal always invoke the listeners in the given order, so if there are 2 listeners with common concerns,only one of them will be effective. > * The Listener gives access to the raw {{java.sql.Connection}} and therefore any error may cause chaos on the pool (leave an invalid connection on the pool, etc.) > * Some methods on the listener are invoked by Agroal's own thread and therefore should not execute any long running task (that is not a problem in the context of this issue, but may be if we expose this interface as API) > * When running Agroal with a TransactionManager, the life-cycle of the connections can be slightly different as this is associated with the transaction. This does not map well on the current listener interface. > A new interface PoolInteceptor should be added to address this issues. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13317) MicroProfile OpenTracing integration requires scope request

by Emmanuel Hugonnet (Jira)

Emmanuel Hugonnet created WFLY-13317: ---------------------------------------- Summary: MicroProfile OpenTracing integration requires scope request Key: WFLY-13317 URL: https://issues.redhat.com/browse/WFLY-13317 Project: WildFly Issue Type: Bug Components: MP OpenTracing Affects Versions: 19.0.0.Final Reporter: Emmanuel Hugonnet Assignee: Emmanuel Hugonnet MicroProfile integration is using a ServletContext which requires requestScope to be active. When trying the MP Rest Client tck with WildFly this requirement creates the following failure: org.jboss.weld.contexts.ContextNotActiveException: WELD-001303: No active contexts for scope type javax.enterprise.context.RequestScoped at org.jboss.weld.core@3.1.3.Final//org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:647) at org.jboss.weld.core@3.1.3.Final//org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:89) at org.jboss.weld.core@3.1.3.Final//org.jboss.weld.bean.ContextualInstance.getIfExists(ContextualInstance.java:63) at org.jboss.weld.core@3.1.3.Final//org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:87) at org.jboss.weld.core@3.1.3.Final//org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:105) at org.jboss.weld.core(a)3.1.3.Final//org.jboss.weldx.servlet.ServletContext$$Proxy$_$$_WeldClientProxy.getAttribute(Unknown Source) at org.wildfly.microprofile.opentracing-smallrye@20.0.0.Beta1-SNAPSHOT//org.wildfly.microprofile.opentracing.smallrye.TracerProducer.getTracer(TracerProducer.java:43) -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13293) When deploying "ROOT.war" in EAP7.x, the context root value output through jboss-cli is not valid

by Ricardo Martin Camarero (Jira)

[ https://issues.redhat.com/browse/WFLY-13293?page=com.atlassian.jira.plugi... ] Ricardo Martin Camarero commented on WFLY-13293: ------------------------------------------------ [~flavia.rainone] [~brian.stansberry] I have been working on this trying to see other alternatives. The summary: * The main problem is that the UndertowDeploymentInfoService.java right now changes the context path at the end [here|https://github.com/wildfly/wildfly/blob/master/undertow/src/main/jav...]. * So the UndertowDeploymentProcessor.java saves in the model and in the alias of the service an incorrect context path. That's why the jboss-cli shows an incorrect value and the root problem. In other parts of the code the context path saved in the model is used to recover the service using the alias. The options I have been managing are the following two: * The first solution I thought and what it's done in the PR. UndertowDeploymentProcessor.java just retrieves the Host service before and calculates the correct context path which is used for everything later (alias, model info, service,...). But there is no dependency over the host as Brian stated. * Other option I have tried is just removing the alias for the service and use the real name which is obtained from the deploymentUnit (it's something like {{jboss.deployment.unit."app.war"}} or {{jboss.deployment.subunit."app.ear"."app.war"}} depending if it's in an ear or not). This means that several classes should also be modified, for example [JaxrsDeploymentDefinition|https://github.com/wildfly/wildfly/blob/master/...] or [DeploymentDefinition|https://github.com/wildfly/wildfly/blob/master/under...]. With this change the service name used is the real one, not the alias. This way the service can be the one that sets the context path in the model with the final value and it has a dependency over the Host. This is a big change, but it seems to work OK. Test pass at least. But I don't know if we can backport something like that (but that is another story). Do you like more the second option? Do I prepare another PR and see if you think that is better? > When deploying "ROOT.war" in EAP7.x, the context root value output through jboss-cli is not valid > ------------------------------------------------------------------------------------------------- > > Key: WFLY-13293 > URL: https://issues.redhat.com/browse/WFLY-13293 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 19.0.0.Final > Reporter: Ricardo Martin Camarero > Assignee: Ricardo Martin Camarero > Priority: Major > > *When deploying "ROOT.war" default context-root is "/" even though i set a specific context-root in jboss-web.xml. However, If I check resources by jboss-cli, it seems like context-root value refers to jboss-web.xml and this value is invalid.* > ROOT.war/WEB-INF/jboss-web.xml > {code} > <jboss-web version="7.0" > xmlns:jboss="http://www.jboss.com/xml/ns/javaee" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee jboss-web_7_0.xsd"> > <context-root>/hello</context-root> > </jboss-web>{code} > {code}[standalone@192.168.122.1:10090 /] deployment-info > NAME RUNTIME-NAME PERSISTENT ENABLED STATUS > ROOT.war ROOT.war true true OK > {code} > server.log > {code} > 2020-03-24 10:35:56,344 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 78) WFLYUT0021: Registered web context: '/' for server 'default-server' > 2020-03-24 10:35:56,354 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0010: Deployed "ROOT.war" (runtime-name : "ROOT.war") > {code} > However, If I check resource by jboss-cli, it seems like context-root value refers to jboss-web.xml and this vaule is invalid. > {code} > [standalone@192.168.122.1:10090 /] /deployment=ROOT.war/subsystem=undertow:read-resource(include-runtime=true) > { > "outcome" => "success", > "result" => { > "active-sessions" => 0, > "context-root" => "/hello", => this is invalid, the real value is "/" > "expired-sessions" => 0, > "highest-session-count" => 0, > "max-active-sessions" => -1, > "rejected-sessions" => 0, > "server" => "default-server", > "session-avg-alive-time" => 0, > "session-max-alive-time" => 0, > "sessions-created" => 0, > "virtual-host" => "default-host", > "servlet" => undefined, > "websocket" => undefined > } > } > {code} > valid context-root is "/" > {code} > [hyoskim@hyoskim sophia]$ curl -v http://192.168.122.1:8180/test.jsp > * About to connect() to 192.168.122.1 port 8180 (#0) > * Trying 192.168.122.1... > * Connected to 192.168.122.1 (192.168.122.1) port 8180 (#0) > > GET /test.jsp HTTP/1.1 > > User-Agent: curl/7.29.0 > > Host: 192.168.122.1:8180 > > Accept: */* > > > < HTTP/1.1 200 OK > < Connection: keep-alive > < X-Powered-By: JSP/2.3 > < Set-Cookie: JSESSIONID=_Ej56uTEuy1B0U2Oi94pcVtCNwg7ngRNr7HO7TQ7.worker1; path=/ > < Content-Type: text/html;charset=ISO-8859-1 > < Content-Length: 6 > < Date: Tue, 24 Mar 2020 01:37:53 GMT > < > hello > [hyoskim@hyoskim sophia]$ curl -v http://192.168.122.1:8180/hello/test.jsp > * About to connect() to 192.168.122.1 port 8180 (#0) > * Trying 192.168.122.1... > * Connected to 192.168.122.1 (192.168.122.1) port 8180 (#0) > > GET /hello/test.jsp HTTP/1.1 > > User-Agent: curl/7.29.0 > > Host: 192.168.122.1:8180 > > Accept: */* > > > < HTTP/1.1 404 Not Found > < Connection: keep-alive > < Content-Type: text/html;charset=UTF-8 > < Content-Length: 74 > < Date: Tue, 24 Mar 2020 01:37:23 GMT > < > * Connection #0 to host 192.168.122.1 left intact > <html><head><title>Error</title></head><body>/hello/test.jsp</body></html>{code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2020