August 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-6951) JacORBSubsystemParser should create an OBJECT param for an OBJECT attribute

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-6951?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-6951: ----------------------------------- Git Pull Request: (was: https://github.com/wildfly/wildfly/pull/8957) > JacORBSubsystemParser should create an OBJECT param for an OBJECT attribute > --------------------------------------------------------------------------- > > Key: WFLY-6951 > URL: https://issues.jboss.org/browse/WFLY-6951 > Project: WildFly > Issue Type: Bug > Components: IIOP > Affects Versions: 10.1.0.CR1 > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Minor > Fix For: 11.0.0.Alpha1 > > > The parser when parsing "properties" elements is producing a DMR param of ModelType.LIST of ModelType.PROPERTY instead of a param of ModelType.OBJECT, which is how the attribute is specified. This works ok although it results in storing the attribute value in non-canonical format. But this behavior blocks completion of WFCORE-1581 because it results in test failures once WFCORE-1581 is implemented. Tests that compare the model structure generated by a current version controller when it executes the parser's ops fail as that structure doesn't match what a legacy version controller produces. The mismatch is largely harmless, but it's much simpler to correct the parser than to code a workaround into the tests. Plus the parser is just wrong. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6950) JacORBSubsystemParser should create an OBJECT param for an OBJECT attribute

by Brian Stansberry (JIRA)

Brian Stansberry created WFLY-6950: -------------------------------------- Summary: JacORBSubsystemParser should create an OBJECT param for an OBJECT attribute Key: WFLY-6950 URL: https://issues.jboss.org/browse/WFLY-6950 Project: WildFly Issue Type: Bug Components: IIOP Affects Versions: 10.1.0.CR1 Reporter: Brian Stansberry Assignee: Brian Stansberry Priority: Minor Fix For: 11.0.0.Alpha1 The parser when parsing "properties" elements is producing a DMR param of ModelType.LIST of ModelType.PROPERTY instead of a param of ModelType.OBJECT, which is how the attribute is specified. This works ok although it results in storing the attribute value in non-canonical format. But this behavior blocks completion of WFCORE-1581 because it results in test failures once WFCORE-1581 is implemented. Tests that compare the model structure generated by a current version controller when it executes the parser's ops fail as that structure doesn't match what a legacy version controller produces. The mismatch is largely harmless, but it's much simpler to correct the parser than to code a workaround into the tests. Plus the parser is just wrong. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBLOGGING-123) Support for tinylog

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/JBLOGGING-123?page=com.atlassian.jira.plu... ] James Perkins commented on JBLOGGING-123: ----------------------------------------- You'd just need to put the service file in tinylog. So basically in tinylog you could just have the {{META-INF/services/org.jboss.logging.LoggerProvider}} with the entry for your tinylog provider. It looks like most of the bindings/facades have their own separate project so you could do that too. If I can find some time maybe I'll do a PR to tinylog if that would work. > Support for tinylog > ------------------- > > Key: JBLOGGING-123 > URL: https://issues.jboss.org/browse/JBLOGGING-123 > Project: JBoss Logging > Issue Type: Feature Request > Reporter: Martin Winandy > Assignee: James Perkins > > tinylog is a lightweight logging framework for Java with a static logger class. For supporting tinylog in JBoss Logging, a logger provider has to be implemented and added to the LoggerProviders class. > Link to tinylog website: http://www.tinylog.org/ > Example implementation for JBoss Logging: https://github.com/pmwmedia/jboss-logging/ > The tinylog implementation for JBoss Logging is out-dated, but I could adapt to the newest version. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-345) Provide way to display deployed application metadata

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-345?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFCORE-345: ----------------------------------------- [~nickarls] What's a DeploymentInfo? There's such a class in Undertow but you filed this before we started moving to Undertow. Another way to phrase the question is I'm not clear on what data you want. You reference filters and request listeners so it sounds like you are looking for information on the webserver's handling of the deployment. > Provide way to display deployed application metadata > ---------------------------------------------------- > > Key: WFCORE-345 > URL: https://issues.jboss.org/browse/WFCORE-345 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Nicklas Karlsson > Assignee: Tomaz Cerar > > It would be handy to have the deployment process print out the complete DeploymentInfo for an application so one could view the final order of filters and request listeners etc. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-328) Provide deployment manifest information via the CLI

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-328?page=com.atlassian.jira.plugin... ] Brian Stansberry reassigned WFCORE-328: --------------------------------------- Assignee: ehsavoie Hugonnet Emmanuel, I'm assigning this to you as it is related to the general :read-content work. I'm not asking you to do anything particular for manifests; I just want to get all these similar ones assigned to you so you can clean them up once you're done. > Provide deployment manifest information via the CLI > --------------------------------------------------- > > Key: WFCORE-328 > URL: https://issues.jboss.org/browse/WFCORE-328 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI, Domain Management > Reporter: Brian Stansberry > Assignee: ehsavoie Hugonnet > > We've gotten a user request for providing the contents of a deployment's MANIFEST.MF via the CLI. > The request is to include an option to get the manifest info for a single deployment, and also the info for all deployments. > This task needs to be evaluated in relationship to the larger request to provide read (and possibly in some cases write) access to all files within a deployment. The manifest is essentially just one file with a standard location. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1247) ForceEagerActivationOption may cause a recursive segment initialization

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1247?page=com.atlassian.jira.plugi... ] Mario Fusco commented on DROOLS-1247: ------------------------------------- Partially fixed by https://github.com/droolsjbpm/drools/commit/45fb1d622759d3f439b9a089fa1b5... There is still one unresolved test failure that needs to be investigated and fixed https://github.com/droolsjbpm/drools/commit/45fb1d622759d3f439b9a089fa1b5... The NPE in that test is caused by the fact that the same NotNode is evaluated twice during the same flushing operation and the second time there is a staged child left tuple that it tries to remove. The problem is that the node is not the tip of the segment so there isn't actually any staged list to be cleared and the NPE is thrown when the node tries to do so. The other interesting fact is that the path is already totally linked during that evaluation so it would also important to figure out why the same test doesn't fail in lazy mode. > ForceEagerActivationOption may cause a recursive segment initialization > ----------------------------------------------------------------------- > > Key: DROOLS-1247 > URL: https://issues.jboss.org/browse/DROOLS-1247 > Project: Drools > Issue Type: Bug > Components: core engine > Reporter: Mario Fusco > Assignee: Mario Fusco > Priority: Blocker > > ForceEagerActivationOption may cause a recursive segments initialization resulting in an infinite recursive linked list of segment memories like: smem1 -> smem2 -> smem1 -> ... When this happens the segments evaluation makes the engine to fall in an endless loop. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6331) Add helper method to get network addresses of the host

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6331?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-6331: ------------------------------ Component/s: Web (Undertow) > Add helper method to get network addresses of the host > ------------------------------------------------------ > > Key: WFLY-6331 > URL: https://issues.jboss.org/browse/WFLY-6331 > Project: WildFly > Issue Type: Task > Components: Web (Undertow) > Reporter: Gytis Trikleris > Assignee: Tomaz Cerar > > It would be good to have a way to get network addresses which could be used to access endpoints deployed to the particular host. > Here is the example use case: > XTS subsystem depends on a particular host to which it deploys its services. With WS-Coordination request it returns URL which can be used to control transaction. We need a way to get the address of that particular host, so that correct URL could be generated in every scenario (currently it depends on WS subsystem and fails if jboss.undefined.host is set to wsld-host). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-407) Console should display deployment status

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-407?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFCORE-407: ----------------------------------------- I'm going to move this to the HAL project, which is where console changes are made. A deployment resource includes a 'status' attribute, which is distinct information from 'enabled.' The 'status' is a runtime attribute so it is not present on the domain level deployment resources, only those on a server. > Console should display deployment status > ---------------------------------------- > > Key: WFCORE-407 > URL: https://issues.jboss.org/browse/WFCORE-407 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Environment: Redhat Linux 4 (??). Kernel version is: 2.6.18-194.26.1.el5 > Reporter: B K > Labels: jboss > > The error found in the server log files was: > 13:58:40,009 INFO [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report > JBAS014777: Services which failed to start: service jboss.web.deployment.default-host./apex: org.jboss.msc.service.StartException in service jboss.web.deployment.default-host./apex: JBAS018040: Failed to start context > Occurence details: > 1. The issue occured following a restart of the application server > Analysis details: > 1. From the perspective of the JBOSS 7 admin console ... the admin console shows that the "apex.war" application is deployed and "enabled". I believe it should not display "enabled" as the context has failed to start and it is NOT capable of servicing requests. > Details to reproduce: > 1. Download Oracle Apex Listener 1.1.4 from: > http://www.oracle.com/technetwork/developer-tools/apex-listener/downloads... > 2. Unzip the war file e.g jar xvf apex.war > 3. Modify the web.xml by adding: > <context-param> > <param-name>config.dir</param-name> > <param-value>/opt/jboss/apex_config_dir</param-value> > </context-param> > 4. Create the path "/opt/jboss/apex_config_dir". > 5. Zip the war file. > cd locationContaining the Web-INF directory > jar cvf apex.war * > 6. Deploy war file and enable via admin console. Stop Server. Start server. > 7. Exception occurs. > NOTE: there could be an additional step to reproduce. Will detail if above does not work. > NOTE2: I can redeploy the above application and get it working again by removing some files that are auto generated by apex.war (so a partial bit of this issue is probably application related). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-407) Console should display deployment status

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-407?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-407: ------------------------------------ Summary: Console should display deployment status (was: JBAS018040: Failed to start context) > Console should display deployment status > ---------------------------------------- > > Key: WFCORE-407 > URL: https://issues.jboss.org/browse/WFCORE-407 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Environment: Redhat Linux 4 (??). Kernel version is: 2.6.18-194.26.1.el5 > Reporter: B K > Labels: jboss > > The error found in the server log files was: > 13:58:40,009 INFO [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report > JBAS014777: Services which failed to start: service jboss.web.deployment.default-host./apex: org.jboss.msc.service.StartException in service jboss.web.deployment.default-host./apex: JBAS018040: Failed to start context > Occurence details: > 1. The issue occured following a restart of the application server > Analysis details: > 1. From the perspective of the JBOSS 7 admin console ... the admin console shows that the "apex.war" application is deployed and "enabled". I believe it should not display "enabled" as the context has failed to start and it is NOT capable of servicing requests. > Details to reproduce: > 1. Download Oracle Apex Listener 1.1.4 from: > http://www.oracle.com/technetwork/developer-tools/apex-listener/downloads... > 2. Unzip the war file e.g jar xvf apex.war > 3. Modify the web.xml by adding: > <context-param> > <param-name>config.dir</param-name> > <param-value>/opt/jboss/apex_config_dir</param-value> > </context-param> > 4. Create the path "/opt/jboss/apex_config_dir". > 5. Zip the war file. > cd locationContaining the Web-INF directory > jar cvf apex.war * > 6. Deploy war file and enable via admin console. Stop Server. Start server. > 7. Exception occurs. > NOTE: there could be an additional step to reproduce. Will detail if above does not work. > NOTE2: I can redeploy the above application and get it working again by removing some files that are auto generated by apex.war (so a partial bit of this issue is probably application related). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-431) Score Cards: Duplicate Rule and Declarative Types when generating DRL

by Davide Sottara (JIRA)

[ https://issues.jboss.org/browse/DROOLS-431?page=com.atlassian.jira.plugin... ] Davide Sottara commented on DROOLS-431: --------------------------------------- Can you share a scorecard that causes the problem? Also, what version are you using? Thanks > Score Cards: Duplicate Rule and Declarative Types when generating DRL > --------------------------------------------------------------------- > > Key: DROOLS-431 > URL: https://issues.jboss.org/browse/DROOLS-431 > Project: Drools > Issue Type: Bug > Affects Versions: 6.0.0.Final > Reporter: Michael Anstis > Assignee: Davide Sottara > > See test droolsjbpm/drools/drools-workbench-models/drools-workbench-models-guided-scorecard/GuidedScoreCardIntegrationTest.java -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2016