October 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-4163) Easier API for creating capability ServiceNames from DUPs and deployment services

by Brian Stansberry (Jira)

Brian Stansberry created WFCORE-4163: ---------------------------------------- Summary: Easier API for creating capability ServiceNames from DUPs and deployment services Key: WFCORE-4163 URL: https://issues.jboss.org/browse/WFCORE-4163 Project: WildFly Core Issue Type: Enhancement Components: Management Reporter: Brian Stansberry Assignee: Jeff Mesnil Code like this is starting to proliferate: CapabilityServiceSupport capabilityServiceSupport = deploymentUnit.getAttachment(org.jboss.as.server.deployment.Attachments.CAPABILITY_SERVICE_SUPPORT); ServiceName serviceName = capabilityServiceSupport.getCapabilityServiceName("org.wildfly.foo.bar"); Perhaps just this? ServiceName serviceName = deploymentUnit.getCapabilityServiceName("org.wildfly.foo.bar"); -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11169) Default ASYM_ENCRYPT asym_keylength is considered breakable

by Radoslav Husar (Jira)

Radoslav Husar created WFLY-11169: ------------------------------------- Summary: Default ASYM_ENCRYPT asym_keylength is considered breakable Key: WFLY-11169 URL: https://issues.jboss.org/browse/WFLY-11169 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 14.0.0.Final Reporter: Radoslav Husar Assignee: Radoslav Husar Fix For: 15.0.0.Alpha1 JGroups default asym_keylength is 512, however RSA keys less than 1024 bits are considered breakable. We should baseline the default to a secure size universally supported in our supported JDKs. Since JDK8 the default is 2048. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9587) Investigate and introduce capabilities for the transactional subsytems transations/xts/rts

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-9587?page=com.atlassian.jira.plugin.... ] Brian Stansberry edited comment on WFLY-9587 at 10/12/18 1:41 PM: ------------------------------------------------------------------ As part of our work on getting maximum benefit from Galleon, we want to eliminate unnecessary hard dependencies between modules, and a good candidate for that is dependencies on the org.jboss.as.transactions module. See WFLY-11165. This JIRA has some complex aspects, e.g. JTS or perhaps capabilities for some less commonly used services provided by the subsystem. But there are a couple simpler cases that if handled will go a very long way toward eliminating most uses of org.jboss.as.transactions. So I'd like to create subtasks for these and get them sorted today: 1) TransactionManager, UserTransaction and TransactionSynchronizationRegistry. The services for these are always installed if the subsystem is installed and the service value type are clearly "stable" API classes. So it seems trivial to add a capability for these. 2) XAResourceRecoveryRegistry. The service for this is always installed if the subsystem is installed. The service value type is not as obviously "stable" as TransactionManager and TransactionSynchronizationRegistry, so I think this should be a separate issue to allow it to be rejected etc if not wanted. was (Author: brian.stansberry): As part of our work on getting maximum benefit from Galleon, we want to eliminate unnecessary hard dependencies between modules, and a good candidate for that is dependencies on the org.jboss.as.transactions module. See WFLY-11165. This JIRA has some complex aspects, e.g. JTS or perhaps capabilities for some less commonly used services provided by the subsystem. But there are a couple simpler cases that if handled will go a very long way toward eliminating most uses of org.jboss.as.transactions. So I'd like to create subtasks for these and get them sorted today: 1) TransactionManager and TransactionSynchronizationRegistry. The services for these are always installed if the subsystem is installed and the service value type are clearly "stable" API classes. So it seems trivial to add a capability for these. 2) XAResourceRecoveryRegistry. The service for this is always installed if the subsystem is installed. The service value type is not as obviously "stable" as TransactionManager and TransactionSynchronizationRegistry, so I think this should be a separate issue to allow it to be rejected etc if not wanted. > Investigate and introduce capabilities for the transactional subsytems transations/xts/rts > ------------------------------------------------------------------------------------------ > > Key: WFLY-9587 > URL: https://issues.jboss.org/browse/WFLY-9587 > Project: WildFly > Issue Type: Feature Request > Components: Transactions, XTS > Affects Versions: 11.0.0.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Major > > The notion of capability is not introduced to the transactional system. The WFLY integration expecting subsystem providing it. The transaction subsystems should support so. > https://docs.jboss.org/author/display/WFLY/Working+with+WildFly+Capabilities -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11166) Create capabilities for TransactionManager, UserTransaction and TransactionSynchronizationRegistry

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-11166?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFLY-11166: ------------------------------------ Summary: Create capabilities for TransactionManager, UserTransaction and TransactionSynchronizationRegistry (was: Create capabilities for TransactionManager and TransactionSynchronizationRegistry) > Create capabilities for TransactionManager, UserTransaction and TransactionSynchronizationRegistry > -------------------------------------------------------------------------------------------------- > > Key: WFLY-11166 > URL: https://issues.jboss.org/browse/WFLY-11166 > Project: WildFly > Issue Type: Sub-task > Components: Management, Transactions > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Major > > See https://issues.jboss.org/browse/WFLY-9587?focusedCommentId=13647549&page=... in the parent issue. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11168) UncheckedStatelessBean uses EJB extension components

by James Perkins (Jira)

[ https://issues.jboss.org/browse/WFLY-11168?page=com.atlassian.jira.plugin... ] James Perkins moved JBEAP-15658 to WFLY-11168: ---------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-11168 (was: JBEAP-15658) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: EJB Test Suite (was: EJB) (was: Test Suite) Target Release: (was: 7.backlog.GA) > UncheckedStatelessBean uses EJB extension components > ---------------------------------------------------- > > Key: WFLY-11168 > URL: https://issues.jboss.org/browse/WFLY-11168 > Project: WildFly > Issue Type: Bug > Components: EJB, Test Suite > Reporter: James Perkins > Assignee: Farah Juma > Priority: Major > > The {{UncheckedStatelessBean}} test uses the {{org.jboss.as.ejb3.context.SessionContextImpl}} from the EJB extension to get the roles. If possible this should be refactored to use a public API as that's how users would get the values. If this can be fixed the {{org.wildfly:wildfly-ejb3}} dependency should be removed from the basic integration tests. > [~fjuma] I only assigned this to you as it looks like you updated the test. If someone else should look at this please feel free to reassign. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4162) Incorrect OperationContext.getCapabilityServiceName javadoc

by Brian Stansberry (Jira)

Brian Stansberry created WFCORE-4162: ---------------------------------------- Summary: Incorrect OperationContext.getCapabilityServiceName javadoc Key: WFCORE-4162 URL: https://issues.jboss.org/browse/WFCORE-4162 Project: WildFly Core Issue Type: Bug Components: Management Reporter: Brian Stansberry Assignee: Jeff Mesnil The OperationContext.getCapabilityServiceName javadoc is incorrect with respect to the handling of the 'serviceType' param. I believe at this point it can be null, and IAE will not be thrown if it is. Passing the serviceType basically turns on optional validation that the capability actually exposes a matching type. Passing null means don't bother checking, which is valid and probably preferable. Perhaps an overloaded variant of this that takes no serviceType would be useful. Here's the kind of heavy boilerplate the current API encourages: .addDependency(context.getCapabilityServiceName("org.wildfly.transactions.transaction-manager", TransactionManager.class), TransactionManager.class, fileTimerPersistence.getTransactionManager()) -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11167) Create capability for XAResourceRecoveryRegistry

by Brian Stansberry (Jira)

Brian Stansberry created WFLY-11167: --------------------------------------- Summary: Create capability for XAResourceRecoveryRegistry Key: WFLY-11167 URL: https://issues.jboss.org/browse/WFLY-11167 Project: WildFly Issue Type: Sub-task Components: Management, Transactions Reporter: Brian Stansberry Assignee: Brian Stansberry See https://issues.jboss.org/browse/WFLY-9587?focusedCommentId=13647549&page=... in the parent issue. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11166) Create capabilities for TransactionManager and TransactionSynchronizationRegistry

by Brian Stansberry (Jira)

Brian Stansberry created WFLY-11166: --------------------------------------- Summary: Create capabilities for TransactionManager and TransactionSynchronizationRegistry Key: WFLY-11166 URL: https://issues.jboss.org/browse/WFLY-11166 Project: WildFly Issue Type: Sub-task Components: Management, Transactions Reporter: Brian Stansberry Assignee: Brian Stansberry See https://issues.jboss.org/browse/WFLY-9587?focusedCommentId=13647549&page=... in the parent issue. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9587) Investigate and introduce capabilities for the transactional subsytems transations/xts/rts

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-9587?page=com.atlassian.jira.plugin.... ] Brian Stansberry commented on WFLY-9587: ---------------------------------------- As part of our work on getting maximum benefit from Galleon, we want to eliminate unnecessary hard dependencies between modules, and a good candidate for that is dependencies on the org.jboss.as.transactions module. See WFLY-11165. This JIRA has some complex aspects, e.g. JTS or perhaps capabilities for some less commonly used services provided by the subsystem. But there are a couple simpler cases that if handled will go a very long way toward eliminating most uses of org.jboss.as.transactions. So I'd like to create subtasks for these and get them sorted today: 1) TransactionManager and TransactionSynchronizationRegistry. The services for these are always installed if the subsystem is installed and the service value type are clearly "stable" API classes. So it seems trivial to add a capability for these. 2) XAResourceRecoveryRegistry. The service for this is always installed if the subsystem is installed. The service value type is not as obviously "stable" as TransactionManager and TransactionSynchronizationRegistry, so I think this should be a separate issue to allow it to be rejected etc if not wanted. > Investigate and introduce capabilities for the transactional subsytems transations/xts/rts > ------------------------------------------------------------------------------------------ > > Key: WFLY-9587 > URL: https://issues.jboss.org/browse/WFLY-9587 > Project: WildFly > Issue Type: Feature Request > Components: Transactions, XTS > Affects Versions: 11.0.0.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Major > > The notion of capability is not introduced to the transactional system. The WFLY integration expecting subsystem providing it. The transaction subsystems should support so. > https://docs.jboss.org/author/display/WFLY/Working+with+WildFly+Capabilities -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2839) Document how to run Drools with a flat classpath by merging kie.conf files

by Mario Fusco (Jira)

[ https://issues.jboss.org/browse/DROOLS-2839?page=com.atlassian.jira.plugi... ] Mario Fusco resolved DROOLS-2839. --------------------------------- Resolution: Done Documented by https://github.com/kiegroup/kie-docs/commit/f87efa7c5f2fef4bb500659aa9992... > Document how to run Drools with a flat classpath by merging kie.conf files > -------------------------------------------------------------------------- > > Key: DROOLS-2839 > URL: https://issues.jboss.org/browse/DROOLS-2839 > Project: Drools > Issue Type: Task > Components: docs > Affects Versions: 7.9.0.Final > Reporter: Duncan Doyle > Assignee: Mario Fusco > Priority: Major > > When running Drools in a Fat JAR, for example created by the Maven Shade Plugin, the various "kie.conf" files of the Drools JARs (e.g. drools-core, drools-compiler) need to be merged, otherwise , the Fat JAR will contain only 1 kie.conf from a single dependency, resulting into errors. > This is for example required when running Drools in a Vert.x application. > You can merge resources in the Maven Shade Plugin using transformers, like this: > {code} > <transformer implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer"> > <resource>META-INF/kie.conf</resource> > </transformer> > {code} > For example, in my Vert.x app this is the full config of the Maven Shade Plugin: > {code} > <plugin> > <groupId>org.apache.maven.plugins</groupId> > <artifactId>maven-shade-plugin</artifactId> > <version>3.1.0</version> > <executions> > <execution> > <phase>package</phase> > <goals> > <goal>shade</goal> > </goals> > <configuration> > <transformers> > <transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer"> > <manifestEntries> > <Main-Class>io.vertx.core.Launcher</Main-Class> > <Main-Verticle>${main.verticle}</Main-Verticle> > </manifestEntries> > </transformer> > <transformer implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer"> > <resource>META-INF/services/io.vertx.core.spi.VerticleFactory</resource> > </transformer> > <transformer implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer"> > <resource>META-INF/kie.conf</resource> > </transformer> > </transformers> > <artifactSet> > </artifactSet> > <outputFile>${project.build.directory}/${project.artifactId}-${project.version}-fat.jar</outputFile> > </configuration> > </execution> > </executions> > </plugin> > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 9 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 October 2018