April 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-669) Make it possible to propagate attachments from the operation context to the transformer context

by Kabir Khan (JIRA)

Kabir Khan created WFCORE-669: --------------------------------- Summary: Make it possible to propagate attachments from the operation context to the transformer context Key: WFCORE-669 URL: https://issues.jboss.org/browse/WFCORE-669 Project: WildFly Core Issue Type: Feature Request Components: Domain Management Reporter: Kabir Khan Assignee: Kabir Khan Fix For: 1.0.0.CR1 The transformation context needs attachments, and the operation context attachments should be propagable to the transformation context so that the write attribute handlers can give signals to the transformers. We don't want to propagate everything, so I have created TransformerOperationAttachment which in turn contains attach() methods. Only attachments added there get propagated. One use case is if the old model used child resources, so it has child=1, child=2. If the new model was refactored to use this as a map attribute on the parent resource, when the attribute is overwritten, the transformer needs to create a composite to add what is new, remove what is missing, and update things which were changed. However, this is not known to the transformer. So the idea is that the write attribute handler can use these attachments to signal the transformer about what has been added and removed. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4571) Merge the wildfly BOMs into a single BOM

by Rafael Benevides (JIRA)

[ https://issues.jboss.org/browse/WFLY-4571?page=com.atlassian.jira.plugin.... ] Rafael Benevides commented on WFLY-4571: ---------------------------------------- Maybe I'm wrong, but that's just a dependencyManagement. I don't feel that we are push it down their throats. > Merge the wildfly BOMs into a single BOM > ---------------------------------------- > > Key: WFLY-4571 > URL: https://issues.jboss.org/browse/WFLY-4571 > Project: WildFly > Issue Type: Enhancement > Reporter: Paul Gier > Assignee: Paul Gier > > We had some discussion on the jbossdeveloper list [1] about merging the current wildfly/eap boms into a single one instead of a separate bom for each use case. > The only problematic BOM might be the hibernate3 bom because this includes dependencies which conflict with the hibernate 4 bom. So the hibernate 3 bom will probably need to remain separate. > [1]http://lists.jboss.org/pipermail/jbossdeveloper/2015-April/000347.html -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-585) Offline CLI for a Host Controller

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-585?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-585: ------------------------------------ Fix Version/s: 2.0.0.Beta1 (was: 2.0.0.Alpha1) > Offline CLI for a Host Controller > --------------------------------- > > Key: WFCORE-585 > URL: https://issues.jboss.org/browse/WFCORE-585 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI, Domain Management > Reporter: Brian Stansberry > Assignee: luck3y > Fix For: 2.0.0.Beta1 > > > Direct local administration of a Host Controller running from a WildFly Core-based installation via the CLI without requiring a socket-based connection. The general use case is initial setup type activities where the user doesn't want to have to launch a WF server or HC process and potentially have it be visible on the network. WFLY-3288 is one use case; another is a desire some folks have expressed in being able to do configuration without first having to edit any xml to avoid port conflicts on 9990 or 9999. > > As the CLI is itself embeddable, this also opens up the possibility of embedding the CLI inside some other process (say a test class, a provisioning tool or a jar with a main) and then launching the embedded server and using the embedded CLI as a convenient management tool. > This JIRA is for administering a Host Controller. A separate JIRA, WFCORE-584 is for equivalent functionality for a standalone server. > This will require some rework of the Host Controller / Process Controller relationship, as embedding a PC in the CLI makes no sense. The server-lifecycle control functions of the PC will need to be moved into the same process. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-585) Offline CLI for a Host Controller

by luck3y (JIRA)

[ https://issues.jboss.org/browse/WFCORE-585?page=com.atlassian.jira.plugin... ] luck3y reassigned WFCORE-585: ----------------------------- Assignee: luck3y > Offline CLI for a Host Controller > --------------------------------- > > Key: WFCORE-585 > URL: https://issues.jboss.org/browse/WFCORE-585 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI, Domain Management > Reporter: Brian Stansberry > Assignee: luck3y > Fix For: 2.0.0.Alpha1 > > > Direct local administration of a Host Controller running from a WildFly Core-based installation via the CLI without requiring a socket-based connection. The general use case is initial setup type activities where the user doesn't want to have to launch a WF server or HC process and potentially have it be visible on the network. WFLY-3288 is one use case; another is a desire some folks have expressed in being able to do configuration without first having to edit any xml to avoid port conflicts on 9990 or 9999. > > As the CLI is itself embeddable, this also opens up the possibility of embedding the CLI inside some other process (say a test class, a provisioning tool or a jar with a main) and then launching the embedded server and using the embedded CLI as a convenient management tool. > This JIRA is for administering a Host Controller. A separate JIRA, WFCORE-584 is for equivalent functionality for a standalone server. > This will require some rework of the Host Controller / Process Controller relationship, as embedding a PC in the CLI makes no sense. The server-lifecycle control functions of the PC will need to be moved into the same process. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-777) Variable length argument lists lose arguments in MVEL

by Myroslava Dzikovska (JIRA)

Myroslava Dzikovska created DROOLS-777: ------------------------------------------ Summary: Variable length argument lists lose arguments in MVEL Key: DROOLS-777 URL: https://issues.jboss.org/browse/DROOLS-777 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 6.1.0.Final Environment: RHEL 6, OpenJDK Runtime Environment (rhel-2.5.5.1.el6_6-x86_64 u79-b14) Reporter: Myroslava Dzikovska Assignee: Mario Fusco When I use a method with variable number of arguments (e.g., String... args) in MVEL, the first one is passed on, and the others are discarded, leading to confusing and difficult to debug bugs. It should either support this, or report a compilation error. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBLOGGING-114) jboss-logging OSGi bundle requiring optional packages

by Brett Meyer (JIRA)

[ https://issues.jboss.org/browse/JBLOGGING-114?page=com.atlassian.jira.plu... ] Brett Meyer updated JBLOGGING-114: ---------------------------------- Summary: jboss-logging OSGi bundle requiring optional packages (was: jboss-logging's OSGi metadata is somehow wrong) > jboss-logging OSGi bundle requiring optional packages > ----------------------------------------------------- > > Key: JBLOGGING-114 > URL: https://issues.jboss.org/browse/JBLOGGING-114 > Project: JBoss Logging > Issue Type: Bug > Reporter: Steve Ebersole > Assignee: James Perkins > > Apparently jboss-logging places a non-optional dependency on log4j: > {noformat} > [22:04] <sebersole> dmlloyd: if you are around... > [22:04] <sebersole> we are having trouble with hibernate-osgi because of jboss-logging jar > [22:04] <sebersole> it essentially requires log4j > [22:05] <sebersole> [22:03] <brmeyer> their manifest has resolution:=optional for every org.apache.log4j package *except* for .message > [22:05] <sebersole> tbh, thats all just gibberish to me. he might as well be speaking chinese > [22:06] <sebersole> but when we try to deploy into karaf, we do get errors installing our features because the jboss-logging bundle fails to start because log4j isnt installed > [22:06] <sebersole> it works when we install log4j first as well > [22:06] <sebersole> even though we are not using log4j > {noformat} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBEE-160) jboss-transaction-api OSGi bundle requiring optional packages

by Brett Meyer (JIRA)

Brett Meyer created JBEE-160: -------------------------------- Summary: jboss-transaction-api OSGi bundle requiring optional packages Key: JBEE-160 URL: https://issues.jboss.org/browse/JBEE-160 Project: JBoss JavaEE Spec APIs Issue Type: Bug Reporter: Brett Meyer Assignee: Shelly McGowan The jboss-transaction-api_1.2_spec OSGi bundle requires the 'javax.enterprise.context'. Instead, that should be optional, right? cdi-api shouldn't be required to simply use jta. Thanks! -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBLOGGING-114) jboss-logging's OSGi metadata is somehow wrong

by Brett Meyer (JIRA)

[ https://issues.jboss.org/browse/JBLOGGING-114?page=com.atlassian.jira.plu... ] Brett Meyer commented on JBLOGGING-114: --------------------------------------- Nope, that's it. For this specific one, jboss-logging simply needs to make org.apache.logging.log4j.message optional in the manifest, I believe. > jboss-logging's OSGi metadata is somehow wrong > ---------------------------------------------- > > Key: JBLOGGING-114 > URL: https://issues.jboss.org/browse/JBLOGGING-114 > Project: JBoss Logging > Issue Type: Bug > Reporter: Steve Ebersole > Assignee: James Perkins > > Apparently jboss-logging places a non-optional dependency on log4j: > {noformat} > [22:04] <sebersole> dmlloyd: if you are around... > [22:04] <sebersole> we are having trouble with hibernate-osgi because of jboss-logging jar > [22:04] <sebersole> it essentially requires log4j > [22:05] <sebersole> [22:03] <brmeyer> their manifest has resolution:=optional for every org.apache.log4j package *except* for .message > [22:05] <sebersole> tbh, thats all just gibberish to me. he might as well be speaking chinese > [22:06] <sebersole> but when we try to deploy into karaf, we do get errors installing our features because the jboss-logging bundle fails to start because log4j isnt installed > [22:06] <sebersole> it works when we install log4j first as well > [22:06] <sebersole> even though we are not using log4j > {noformat} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4468) Remove JGroups subsystem transformers for version < 1.2.0

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-4468?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-4468: ------------------------------- Fix Version/s: 9.0.0.CR1 > Remove JGroups subsystem transformers for version < 1.2.0 > --------------------------------------------------------- > > Key: WFLY-4468 > URL: https://issues.jboss.org/browse/WFLY-4468 > Project: WildFly > Issue Type: Sub-task > Components: Clustering > Affects Versions: 9.0.0.Beta1 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 9.0.0.CR1 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4571) Merge the wildfly BOMs into a single BOM

by Paul Gier (JIRA)

[ https://issues.jboss.org/browse/WFLY-4571?page=com.atlassian.jira.plugin.... ] Paul Gier commented on WFLY-4571: --------------------------------- The imported dependencies should still only affect the versions of dependencies that the user has already added to their pom. But I agree it kind of makes sense to keep these separate. I'll update the PR. > Merge the wildfly BOMs into a single BOM > ---------------------------------------- > > Key: WFLY-4571 > URL: https://issues.jboss.org/browse/WFLY-4571 > Project: WildFly > Issue Type: Enhancement > Reporter: Paul Gier > Assignee: Paul Gier > > We had some discussion on the jbossdeveloper list [1] about merging the current wildfly/eap boms into a single one instead of a separate bom for each use case. > The only problematic BOM might be the hibernate3 bom because this includes dependencies which conflict with the hibernate 4 bom. So the hibernate 3 bom will probably need to remain separate. > [1]http://lists.jboss.org/pipermail/jbossdeveloper/2015-April/000347.html -- This message was sent by Atlassian JIRA (v6.3.15#6346)

9 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 April 2015