December 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-7722) looking for migration from jboss 5 to wildfly 10. Can we migrate app developed in jsf 2 with richfaces 3.3, to wildfly 10.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7722?page=com.atlassian.jira.plugin.... ] Darran Lofthouse resolved WFLY-7722. ------------------------------------ Assignee: Darran Lofthouse (was: Jason Greene) Resolution: Rejected Jira is for reporting bugs and feature requests, for general requests for assistance please use the user forums: - http://wildfly.org/gethelp/ > looking for migration from jboss 5 to wildfly 10. Can we migrate app developed in jsf 2 with richfaces 3.3, to wildfly 10. > -------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7722 > URL: https://issues.jboss.org/browse/WFLY-7722 > Project: WildFly > Issue Type: Feature Request > Affects Versions: 10.1.0.Final > Reporter: Bindu Mahapatra > Assignee: Darran Lofthouse > > Looking for migration from jboss 5 to wildfly 10. Can we migrate app developed in jsf 2 with richfaces 3.3, to wildfly 10, if yes can you please let me know the steps. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1375) TemplateModel.addRow() throws IlegalArgumentException with incorrect count

by Jozef Marko (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1375?page=com.atlassian.jira.plugi... ] Jozef Marko updated DROOLS-1375: -------------------------------- Description: The given method throws exception if the count of inserted columns differs from count of template variables. The problem is that the exception contains incorrect count of expected columns. (was: The given method throws exception if the amount of inserted columns differs from amount of template variables. The problem is that the exception contains incorrect amount of expected columns.) > TemplateModel.addRow() throws IlegalArgumentException with incorrect count > -------------------------------------------------------------------------- > > Key: DROOLS-1375 > URL: https://issues.jboss.org/browse/DROOLS-1375 > Project: Drools > Issue Type: Bug > Components: decision tables > Affects Versions: 7.0.0.Beta3 > Reporter: Jozef Marko > Assignee: Jozef Marko > Priority: Minor > Labels: reported-by-qe > > The given method throws exception if the count of inserted columns differs from count of template variables. The problem is that the exception contains incorrect count of expected columns. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1375) TemplateModel.addRow() throws IlegalArgumentException with incorrect count

by Jozef Marko (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1375?page=com.atlassian.jira.plugi... ] Jozef Marko updated DROOLS-1375: -------------------------------- Summary: TemplateModel.addRow() throws IlegalArgumentException with incorrect count (was: TemplateModel.addRow() throws IlegalArgumentException with incorrect index) > TemplateModel.addRow() throws IlegalArgumentException with incorrect count > -------------------------------------------------------------------------- > > Key: DROOLS-1375 > URL: https://issues.jboss.org/browse/DROOLS-1375 > Project: Drools > Issue Type: Bug > Components: decision tables > Affects Versions: 7.0.0.Beta3 > Reporter: Jozef Marko > Assignee: Jozef Marko > Priority: Minor > Labels: reported-by-qe > > The given method throws exception if the amount of inserted columns differs from amount of template variables. The problem is that the exception contains incorrect amount of expected columns. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1375) TemplateModel.addRow() throws IlegalArgumentException with incorrect index

by Jozef Marko (JIRA)

Jozef Marko created DROOLS-1375: ----------------------------------- Summary: TemplateModel.addRow() throws IlegalArgumentException with incorrect index Key: DROOLS-1375 URL: https://issues.jboss.org/browse/DROOLS-1375 Project: Drools Issue Type: Bug Components: decision tables Affects Versions: 7.0.0.Beta3 Reporter: Jozef Marko Assignee: Jozef Marko Priority: Minor The given method throws exception if the amount of inserted columns differs from amount of template variables. The problem is that the exception contains incorrect amount of expected columns. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7722) looking for migration from jboss 5 to wildfly 10. Can we migrate app developed in jsf 2 with richfaces 3.3, to wildfly 10.

by Bindu Mahapatra (JIRA)

Bindu Mahapatra created WFLY-7722: ------------------------------------- Summary: looking for migration from jboss 5 to wildfly 10. Can we migrate app developed in jsf 2 with richfaces 3.3, to wildfly 10. Key: WFLY-7722 URL: https://issues.jboss.org/browse/WFLY-7722 Project: WildFly Issue Type: Feature Request Affects Versions: 10.1.0.Final Reporter: Bindu Mahapatra Assignee: Jason Greene Looking for migration from jboss 5 to wildfly 10. Can we migrate app developed in jsf 2 with richfaces 3.3, to wildfly 10, if yes can you please let me know the steps. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7721) Support module slots for foreign JMS bridges

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-7721?page=com.atlassian.jira.plugin.... ] David Lloyd commented on WFLY-7721: ----------------------------------- Probably making the name:slot notation work is the best choice for forward compatibility, and also it should be quite simple to do. > Support module slots for foreign JMS bridges > -------------------------------------------- > > Key: WFLY-7721 > URL: https://issues.jboss.org/browse/WFLY-7721 > Project: WildFly > Issue Type: Feature Request > Components: JMS > Affects Versions: 10.0.0.Final > Reporter: Robert Lee > Assignee: Jeff Mesnil > Labels: artemis, bridge, jmsbridge, modules, slot > > It would be nice to specify the slot, along with the module, for a JMS bridge. > *Use case*: > When setting up a JMS bridge with a foreign JMS system, the "module" option can be used (as a CLI parameter or an XML attribute) to specify the library code for the foreign JMS system, as a JBoss Module. > We have a number of different versions of a legacy messaging API. We have previously set up modules for direct use within our deployed application code, using different slots for different versions of the foreign JMS system. > We are now trying to migrate away from our different messaging systems towards Wildfly/Artemis, and have tried to set up JMS bridges to connect with the different systems. > Unfortunately, it is not possible to use any module slot other than "main" with a JMS bridge. There is no "slot" attribute in the XML, and if we try to use "modulename:slot" notation, then we get an error saying that the module could not be loaded. Turning up debugging shows it is looking for "modulename\:slot:main". > This seems like an omission, and is causing us to have to rework code to avoid the use of slots for different versions of the same library, which seems like a step backwards. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7721) Support module slots for foreign JMS bridges

by Robert Lee (JIRA)

Robert Lee created WFLY-7721: -------------------------------- Summary: Support module slots for foreign JMS bridges Key: WFLY-7721 URL: https://issues.jboss.org/browse/WFLY-7721 Project: WildFly Issue Type: Feature Request Components: JMS Affects Versions: 10.0.0.Final Reporter: Robert Lee Assignee: Jeff Mesnil It would be nice to specify the slot, along with the module, for a JMS bridge. *Use case*: When setting up a JMS bridge with a foreign JMS system, the "module" option can be used (as a CLI parameter or an XML attribute) to specify the library code for the foreign JMS system, as a JBoss Module. We have a number of different versions of a legacy messaging API. We have previously set up modules for direct use within our deployed application code, using different slots for different versions of the foreign JMS system. We are now trying to migrate away from our different messaging systems towards Wildfly/Artemis, and have tried to set up JMS bridges to connect with the different systems. Unfortunately, it is not possible to use any module slot other than "main" with a JMS bridge. There is no "slot" attribute in the XML, and if we try to use "modulename:slot" notation, then we get an error saying that the module could not be loaded. Turning up debugging shows it is looking for "modulename\:slot:main". This seems like an omission, and is causing us to have to rework code to avoid the use of slots for different versions of the same library, which seems like a step backwards. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1556) Poor handling of 'required', 'nillable' and 'alternatives' in AttributeDefinition

by Chao Wang (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1556?page=com.atlassian.jira.plugi... ] Chao Wang commented on WFCORE-1556: ----------------------------------- To apply this new handling of these relations on AD (e.g. required with detection of alternatives), Is there a standard way to transform this kind of attributes relation change for domain mode? I would expect similar approach as setValueConverter() with an AttributeConverter for value change in [AttributeTransformationDescriptionBuilderImpl|https://github.com/wildfly/...], but it does not fit this required, nillable and alternatives change. > Poor handling of 'required', 'nillable' and 'alternatives' in AttributeDefinition > --------------------------------------------------------------------------------- > > Key: WFCORE-1556 > URL: https://issues.jboss.org/browse/WFCORE-1556 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 3.0.0.Alpha13 > > > The handling of the notions of 'required' and 'nillable' don't comply with the specs in https://docs.jboss.org/author/display/WFLY/Description+of+the+Management+..., particularly the "Description of an Attribute" part, where the 'required' and 'alternatives' fields are well described, with their relationship spelled out, while 'nillable' doesn't appear at all. Then in "Description of an Operation Parameter or Return Value" nillable is specified, although I think those descriptions could be tightened up in general. > The read-resource-description output for an attribute doesn't show "required" at all. > After a fair bit of thinking, I've finally recalled why the two separate notions of "required" and "nillable" exist in the first place. > The "required" and "alternatives" pieces go together. Is something required? And then if it is required, an alternative satisfies. So you can have two attributes/params, both required, but they are alternatives so one is defined and the other is not. And this is an ok thing. > And then 'nillable' comes in to help clients understand in a simple way whether they need to account for the possibility an undefined value. Basically: > nillable = !required || alternatives != null > Right now, nillable is implemented as > nillable = !required > There are a number of problems I see with AttributeDefinition: > 1) We don't output the 'required' metadata unless it's an operation param being described. This is contrary to spec. However we shouldn't fix this unless we can have meaningful values for 'required', ones where the value can be true but the attribute/param can still have an undefined value, due to an alternative being present. If we can't fix that, there's no point outputting required as it's just redundant with what we output for 'nillable'. > 2) We do output the 'nillable' metadata, even for attribute descriptions, where it isn't in the spec. But in this case I think we change the spec, as dropping nillable would be an incompatible change. > 3) We don't properly validate the "required but has alternatives case." This can't be validated solely with ParameterValidator impls as those only see a single attribute value and don't have contextual information about other attributes/params. To get around this limitation, devs are saying that attributes with alternatives "allowNull" which is equivalent to saying they are not required. But they are required! So I think a fix for this will require AttributeDefinition itself to validate the overall resource model or operation object, and skip calling the ParameterValidator if the attribute/param is undefined and an alternative is defined. > 4) AttributeDefinition and AbstractAttributeDefinitionBuilder unfortunately have a getter/setter/constructor param for property "allowNull" instead of a property named "required". This is unfortunate because "allowNull" intuitively maps to "nillable", but "required" is a much more useful thing to set. The value of "nillable" can be derived from a "required" setting and an "alternatives" setting, but the value of required cannot be so derived. > I think a fix for this would probably start from 4), deprecating setAllowNull, adding get/setRequired and changing the meaning of the AD(Builder) constructor param to "required". The effect of this would be that all current code setting "allowNull" would now be setting a new "required" field. This should be a non-breaking change as in current code that's the effect anyway. > Next would be to fix 3), by changing how AD validates. > Next would be to change the metadata we output, such that "required" is always present and the "nillable" value is !required || alternatives != null. And change the spec accordingly. > Last, in a separate task, would be to find attributes that were configuring "allowNull = true" solely to allow validation to pass when alternatives are present, and fix them to say "required=false". -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2079) Tooling for credential store manipulation

by Peter Skopek (JIRA)

Peter Skopek created WFCORE-2079: ------------------------------------ Summary: Tooling for credential store manipulation Key: WFCORE-2079 URL: https://issues.jboss.org/browse/WFCORE-2079 Project: WildFly Core Issue Type: Task Components: Security Reporter: Peter Skopek Assignee: Peter Skopek Create script for credential store manipulation, conversion from PicketBox Security Vault and bulk conversion. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-749) JBoss AS lifecycle controlling tests

by Karel Piwko (JIRA)

[ https://issues.jboss.org/browse/WFLY-749?page=com.atlassian.jira.plugin.s... ] Karel Piwko commented on WFLY-749: ---------------------------------- Adding [~mjobanek] to the thread. However, I'm not sure if this issue is still relevant. > JBoss AS lifecycle controlling tests > ------------------------------------ > > Key: WFLY-749 > URL: https://issues.jboss.org/browse/WFLY-749 > Project: WildFly > Issue Type: Task > Components: Test Suite > Reporter: Karel Piwko > Fix For: Awaiting Volunteers > > > Create a test suite that uses Arquillian to control JBoss AS 7 lifecycle in a more precise way, that is: > * DomainClient specific controller > * Asynchronous start, stop > * Manual start after modifying a domain configuration > * Monitoring of container and deployment status > * Forced / programmable kill (cleanup to be investigated here though) > Some of the features would require modifications of Arquillian. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 5 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 December 2016