December 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-4831) Clean up HornetQ modules

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-4831?page=com.atlassian.jira.plugin.... ] Kabir Khan closed WFLY-4831. ---------------------------- > Clean up HornetQ modules > ------------------------ > > Key: WFLY-4831 > URL: https://issues.jboss.org/browse/WFLY-4831 > Project: WildFly > Issue Type: Sub-task > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 10.0.0.Alpha5 > > > With the messaging subsystem becoming legacy and its runtime being removed, there is no sense to keep modules for HornetQ server runtime. > However, we still need modules for: > * HornetQ client (required for forward protocol compatibility) > * HornetQ journal (used by other modules such as the transaction subsystem to provide its logging store) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-5315) Remove the Infinispan Directory integration, moves as an extension provided by Infinispan

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-5315?page=com.atlassian.jira.plugin.... ] Kabir Khan closed WFLY-5315. ---------------------------- > Remove the Infinispan Directory integration, moves as an extension provided by Infinispan > ----------------------------------------------------------------------------------------- > > Key: WFLY-5315 > URL: https://issues.jboss.org/browse/WFLY-5315 > Project: WildFly > Issue Type: Task > Components: Clustering, JPA / Hibernate > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Fix For: 10.0.0.CR1 > > > We decided to remove the Lucene / Infinispan Directory integration from the standard WildFly build, as it requires advanced Infinispan knowledge which is more suited for an Infinispan power user. > Such advanced users should better use the latest version provided by the Infinispan project: Infinispan will provide "add-on" modules for the various WildFly releases. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-4597) Remove classname Strings from XTS subsystem

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-4597?page=com.atlassian.jira.plugin.... ] Kabir Khan closed WFLY-4597. ---------------------------- > Remove classname Strings from XTS subsystem > ------------------------------------------- > > Key: WFLY-4597 > URL: https://issues.jboss.org/browse/WFLY-4597 > Project: WildFly > Issue Type: Task > Components: XTS > Reporter: Paul Robinson > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 10.0.0.Alpha1 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > THe XTS SubSystem has many classnames passed to Jandex as raw Strings. It would be better to use Class#getName as it is type-safe. > When this code was written, this was not possible, due to the nature of the order in which class-loading was done and the fact that the code in question was executed very early in the server boot. I don't remember the specific details. > However, something seems to have changed in WildFly, such that we can now use Class#getName on the classes we require. This issue it to replace all the classname Strings with Class#getName() and to also simplify the code under org.jboss.as.xts.jandex, as a lot of that verbose code was added to to cope with the limitation of not being able to use Class#getName(). -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-4581) Provide a migration management operation for JacORB to OpenJDKOrb

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-4581?page=com.atlassian.jira.plugin.... ] Kabir Khan closed WFLY-4581. ---------------------------- > Provide a migration management operation for JacORB to OpenJDKOrb > ------------------------------------------------------------------ > > Key: WFLY-4581 > URL: https://issues.jboss.org/browse/WFLY-4581 > Project: WildFly > Issue Type: Feature Request > Components: IIOP > Affects Versions: 9.0.0.CR1 > Reporter: Tomasz Adamski > Assignee: Tomasz Adamski > Fix For: 10.0.0.Alpha5 > > > Provide a management operation that performs a one-time conversion from the JacORB subsystem into the JDK Orb subsystem. This allows users using the CLI to perform a migration, as well as tools such as WindUp to also execute the change. > Alternatively emulation of JacORB, using JDK Orb underneath, if viable, could be performed. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-5043) Undertow mod_cluster CLI: Display node's Elected, Read, Transferred, Connected stats

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-5043?page=com.atlassian.jira.plugin.... ] Kabir Khan closed WFLY-5043. ---------------------------- > Undertow mod_cluster CLI: Display node's Elected, Read, Transferred, Connected stats > ------------------------------------------------------------------------------------ > > Key: WFLY-5043 > URL: https://issues.jboss.org/browse/WFLY-5043 > Project: WildFly > Issue Type: Feature Request > Components: Web (Undertow) > Reporter: Michal Karm Babacek > Assignee: Stuart Douglas > Labels: mod_cluster > Fix For: 10.0.0.Beta1 > > > As a follow up to JBEAP-215, this bug report is a member of a series addressing crucial CLI management capabilities. > h3. Implement & Display node's Elected, Read, Transferred and Connected stats > At the moment, this is all there is to see: > {noformat} > "balancer" => { > "qa_balancer" => {"node" => {"worker-2" => { > "load" => 89, > "status" => "NODE_UP", > "context" => {"/clusterbench" => { > "requests" => 0, > "status" => "enabled" > }} > }}}, > ... > {noformat} > Furthermore, at a glance, it appears that a part of the needed stats is a mere placeholder at the moment: [NodeStats.java|https://github.com/undertow-io/undertow/blob/master/core/s...] > h3. Call to action > Display the aforementioned stats for each node. Let me set priorities according to what is really used in the battlefield: > * {color:red}Critical{color}: *Elected* (it is often correlated with *Load* during load metric *history* and *capacity* tuning) > * {color:green}Minor{color}: *Read* > * {color:green}Minor{color}: *Transferred* > * {color:green}Minor{color}: *Connected* -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-4999) XSiteBackupForTestCase tests fail on Windows with IPv6

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-4999?page=com.atlassian.jira.plugin.... ] Kabir Khan closed WFLY-4999. ---------------------------- > XSiteBackupForTestCase tests fail on Windows with IPv6 > ------------------------------------------------------ > > Key: WFLY-4999 > URL: https://issues.jboss.org/browse/WFLY-4999 > Project: WildFly > Issue Type: Bug > Components: Clustering, Test Suite > Affects Versions: 10.0.0.Alpha6 > Reporter: James Perkins > Assignee: Radoslav Husar > Labels: testsuite_stability > Fix For: 10.0.0.Beta1 > > > See http://brontes.lab.eng.brq.redhat.com/project.html?projectId=WF_PullReque... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-5224) Unable to read resource after changing process-id-* in transactions subsystem

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-5224?page=com.atlassian.jira.plugin.... ] Kabir Khan closed WFLY-5224. ---------------------------- > Unable to read resource after changing process-id-* in transactions subsystem > ----------------------------------------------------------------------------- > > Key: WFLY-5224 > URL: https://issues.jboss.org/browse/WFLY-5224 > Project: WildFly > Issue Type: Bug > Components: Transactions > Reporter: Harald Pehl > Assignee: Stefano Maestri > Priority: Critical > Fix For: 10.0.0.CR1 > > > After switching between {{process-id-uuid}} and {{process-id-socket-bindings}} as described in WFLY-2623 a follow-up {{/subsystem=transactions:read-resource}} fails until the server / host is reloaded. > The resource should be readable and return an {{reload-required}} header. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-4864) JSP in web application doesn't get VFS-based security permissions

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-4864?page=com.atlassian.jira.plugin.... ] Kabir Khan closed WFLY-4864. ---------------------------- > JSP in web application doesn't get VFS-based security permissions > ----------------------------------------------------------------- > > Key: WFLY-4864 > URL: https://issues.jboss.org/browse/WFLY-4864 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.0.0.Alpha4 > Reporter: Bartosz Spyrko-Śmietanko > Assignee: Tomaz Cerar > Fix For: 10.0.0.Alpha6 > > Attachments: read-props.war, security.policy > > > Permissions granted to web applications (using vfs:/... codebase) are not available in JSPs. > After deploying the test app, a call to http://localhost:8080/read-props/ gives following error: > Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.util.PropertyPermission" "java.home" "read")" in code source "(file:/Users/spyrkob/workspaces/set/servers/wildfly-10.x/wildfly-10.0.0.Alpha5-SNAPSHOT/standalone/tmp/read-props.war/ <no signer certificates>)" of "org.apache.jasper.servlet.JasperLoader@3cae09bb") > at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:270) > at org.wildfly.security.manager.WildFlySecurityManager.checkPropertyAccess(WildFlySecurityManager.java:493) > at java.lang.System.getProperty(System.java:714) > at org.apache.jsp.index_jsp._jspService(index_jsp.java:95) > at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:433) > ... 33 more -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-4751) JNDI lookups of JMS topics/queues can lead to null return values due to a missing service dependency

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-4751?page=com.atlassian.jira.plugin.... ] Kabir Khan closed WFLY-4751. ---------------------------- > JNDI lookups of JMS topics/queues can lead to null return values due to a missing service dependency > ---------------------------------------------------------------------------------------------------- > > Key: WFLY-4751 > URL: https://issues.jboss.org/browse/WFLY-4751 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 9.0.0.CR1, 10.0.0.Alpha2 > Reporter: jaikiran pai > Assignee: jaikiran pai > Fix For: 9.0.0.CR2, 10.0.0.Alpha3 > > > The HornetQ subsystem allows for defining jms-topic(s) and jms-queus(s) for a hornetq-server. The jms-topic(s) and jms-queue(s) allow for JNDI names to be specified for each of those JMS destinations. For each of these jms-topic(s) and jms-queues(s) the HornetQ subsystem does the following: > - Set up JMSTopicService and JMSQueueService depending on the destination type. > - These services in their start method use HornetQ APIs to create the destinations. Note that JNDI binding of these destinations is *not* > done at this point via the HornetQ APIs and instead (is rightly) left for the (WildFly) BinderService(s) to take care off. > - The getValue() method of these services return the Topic/Queue that was created by the services' start using HornetQ API > > - For each of the destinations, the HornetQ subsystem sets up a BinderService each for the JNDI names specified for those destinations. The BinderService is configured to fetch the bound value via the JMSTopicService/JMSQueueService (i.e. they use ValueManagedReferenceFactory which ultimately ends up in a call to getValue() of those services). > Looks fine, except that the BinderService(s) have *not* been setup to "depend" on the JMSTopicService/JMSQueueService. > As a result, in theory (and I suspect in reality here https://developer.jboss.org/thread/259981?start=0&tstart=0) JNDI lookups for the topic/queue (even when proper dependencies are setup between the deployments and the BinderService) can end up returning null values, since although the BinderService is up and running, the backing JMSTopicService or JMSQueueService which are responsible for providing the bound value are not yet started and the topic/queue hasn't yet been created. > P.S: I don't have a way to reproduce this, since it all depends on the service startup timings. I however do suspect that this is what is causing those issues in that thread. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-4766) Filter matching static resource confuses servlet matching logic

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-4766?page=com.atlassian.jira.plugin.... ] Kabir Khan closed WFLY-4766. ---------------------------- > Filter matching static resource confuses servlet matching logic > --------------------------------------------------------------- > > Key: WFLY-4766 > URL: https://issues.jboss.org/browse/WFLY-4766 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 8.1.0.Final, 8.2.0.Final, 9.0.0.CR2, 10.0.0.Alpha2 > Reporter: Peter Major > Assignee: Stuart Douglas > Fix For: 9.0.0.Final, 10.0.0.Beta1 > > Attachments: hello.war > > > Imagine the following setup: > * There are static files stored under the servlet context in the helloworld folder > * there is a servlet mapped to /hello/* > * there is a filter configured to match /helloworld/index.html > For some reason with this set up the end result is that when I request /helloworld or /helloworld/index.html then the servlet is displayed instead of my static files (note that welcome-file-list was configured for index.html). As /hello/* *really* shouldn't match /helloworld I can only think that this is a bug in wildfly, possibly somewhere in undertow. > Oddly enough, once the filter mapping is removed, suddenly the static file is served correctly, so the filter must have some role in this issue. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 1 month

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2017