February 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-3542) Elytron JDBC realm password mapping is not consistent with underlying implementation

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3542?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3542: ------------------------------------- Fix Version/s: 4.0.0.Beta1 (was: 4.0.0.Alpha10) > Elytron JDBC realm password mapping is not consistent with underlying implementation > ------------------------------------------------------------------------------------ > > Key: WFCORE-3542 > URL: https://issues.jboss.org/browse/WFCORE-3542 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: David Lloyd > Assignee: Darran Lofthouse > Fix For: 4.0.0.Beta1 > > > There is no way to configure the JDBC realm to use modular crypt in WildFly, even though the underlying realm does support it. > The problem is that the {{salt-index}} and {{itereration-count-index}} attributes should be optional, and if they not given, a value of {{-1}} should be passed to the mapper. By omitting both of these values, the database column values will then be recognized as modular-crypt strings. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3527) Remove OSGi obsolete code

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3527?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3527: ------------------------------------- Fix Version/s: 4.0.0.Beta1 (was: 4.0.0.Alpha10) > Remove OSGi obsolete code > ------------------------- > > Key: WFCORE-3527 > URL: https://issues.jboss.org/browse/WFCORE-3527 > Project: WildFly Core > Issue Type: Enhancement > Components: Server > Affects Versions: 4.0.0.Alpha5 > Reporter: Richard Opalka > Assignee: Richard Opalka > Fix For: 4.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3522) Module dependency order for a deployment is wrong

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3522?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3522: ------------------------------------- Fix Version/s: 4.0.0.Beta1 (was: 4.0.0.Alpha10) > Module dependency order for a deployment is wrong > ------------------------------------------------- > > Key: WFCORE-3522 > URL: https://issues.jboss.org/browse/WFCORE-3522 > Project: WildFly Core > Issue Type: Bug > Affects Versions: 3.0.8.Final > Reporter: Ken Finnigan > Assignee: David Lloyd > Priority: Blocker > Fix For: 4.0.0.Beta1, 3.1.0.Final > > > Within WildFly Swarm we need the ability to override the `javax.ws.rs.client.ClientBuilder` service file for a deployment to provide custom handling for implementing Eclipse MicroProfile. > With a service file present in the deployment, the existing RESTEasy service file is always found first because the deployment module is added as a dependency after other non local dependencies. See https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/... > After discussing with [~dmlloyd] on IRC, he agreed this was a bug and a better solution was for the deployment's dependency to always be first if `isLocalLast()` is false, and instead remove any spec packages that might be present on the deployment path instead. > He explained the purpose of this ordering was to prevent a user deploying `javax.servlet.api` and breaking things, but it appears this can be achieved by alternative methods. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9795) Intermittent failure in ManagementOnlyModeTestCase

by Stuart Douglas (JIRA)

Stuart Douglas created WFLY-9795: ------------------------------------ Summary: Intermittent failure in ManagementOnlyModeTestCase Key: WFLY-9795 URL: https://issues.jboss.org/browse/WFLY-9795 Project: WildFly Issue Type: Bug Reporter: Stuart Douglas Assignee: Stuart Douglas -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9604) wildfly-11.0.0.Final JPA

by Trond Arild Lode Tobiassen Heidelberg (JIRA)

[ https://issues.jboss.org/browse/WFLY-9604?page=com.atlassian.jira.plugin.... ] Trond Arild Lode Tobiassen Heidelberg commented on WFLY-9604: ------------------------------------------------------------- Brian: Do you know if there has been a bug/RFE? Seems if not I need to rewrite my application to accomodate hibernate requirements. > wildfly-11.0.0.Final JPA > ------------------------ > > Key: WFLY-9604 > URL: https://issues.jboss.org/browse/WFLY-9604 > Project: WildFly > Issue Type: Feature Request > Components: JPA / Hibernate > Affects Versions: 11.0.0.Final > Environment: Javaee 7, Windows 7, jdk 8 151 > Reporter: Trond Arild Lode Tobiassen Heidelberg > Labels: task > Fix For: 12.0.0.Alpha1 > > > I am deploying to above. I get this error message: > > {"jboss.persistenceunit.registrar#REGDB" => "org.hibernate.AnnotationException: Property no.tobiassenit.sipstack.sip.message.AbstractMessage.part has an unbound type and no explicit target entity. Resolve this Generic usage issue or set an explicit target attribute (eg @OneToMany(target=) or use an explicit @Type Caused by: org.hibernate.AnnotationException: Property no.tobiassenit.sipstack.sip.message.AbstractMessage.part has an unbound type and no explicit target entity. Resolve this Generic usage issue or set an explicit target attribute (eg @OneToMany(target=) or use an explicit @Type"}, > > > I have this code: > > @OneToOne(optional = true, cascade = CascadeType.ALL, targetEntity = AbstractPart.class) > @JoinColumn(name = "PART", unique = false, nullable = true, updatable = false) > protected X part; > What about the target= vs the targetEntity=? There is no target attribute or @Type annotation available. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9792) Make it easier to switch the maven groupId in different branches

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-9792?page=com.atlassian.jira.plugin.... ] Brian Stansberry resolved WFLY-9792. ------------------------------------ Resolution: Done The further change I wanted to do isn't feasible at this time; see WFBUILD-36. > Make it easier to switch the maven groupId in different branches > ---------------------------------------------------------------- > > Key: WFLY-9792 > URL: https://issues.jboss.org/browse/WFLY-9792 > Project: WildFly > Issue Type: Task > Components: Build System > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 12.0.0.Alpha1 > > > Different branches of our code use different Maven groupId values for the modules. Simplify the task of this conversion by: > 1) Avoiding hard-coding of the groupId anywhere where it is not required, using {code}${project.groupId}{code} instead. Goal is to limit declaration of the group id to the root pom and to the groupId child element in each pom's "parent" element. Changing the groupId then becomes a task analogous to changing the maven version. > 2) Eliminating unnecessary groupId elements where a child pom redundantly declares the groupId inherited from its parent. > 3) Separating groupId elements from version elements by making sure artifactId is in between (rather than before groupId as is currently done in some poms.) This will help avoid spurious conflicts between commits the update the groupId and those that update the version. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFBUILD-36) Support resolution of ${project.groupId} in the server-provisioning.xml file

by Brian Stansberry (JIRA)

Brian Stansberry created WFBUILD-36: --------------------------------------- Summary: Support resolution of ${project.groupId} in the server-provisioning.xml file Key: WFBUILD-36 URL: https://issues.jboss.org/browse/WFBUILD-36 Project: WildFly Build Tools Issue Type: Enhancement Reporter: Brian Stansberry Assignee: Stuart Douglas Priority: Minor The provisioning plugin allows parameterization of a feature pack's version via ```${project.version}``` but parameterizing the groupId via ```${project.groupId}``` isn't supported. My guess is something like this for groupId would do the trick: https://github.com/wildfly/wildfly-build-tools/blob/master/provisioning-m... This would make it easier to use the same provisioning configs in different branches that have different maven groupIds. I see the TODO about the project.version thing I linked above, and I understand I'm asking to expand a concept that the TODO indicates is suspect. So I won't be offended if this is rejected. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9792) Make it easier to switch the maven groupId in different branches

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-9792?page=com.atlassian.jira.plugin.... ] Brian Stansberry reopened WFLY-9792: ------------------------------------ Reopening as I also need to update the server-provisioning.xml files to use project.groupId. > Make it easier to switch the maven groupId in different branches > ---------------------------------------------------------------- > > Key: WFLY-9792 > URL: https://issues.jboss.org/browse/WFLY-9792 > Project: WildFly > Issue Type: Task > Components: Build System > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 12.0.0.Alpha1 > > > Different branches of our code use different Maven groupId values for the modules. Simplify the task of this conversion by: > 1) Avoiding hard-coding of the groupId anywhere where it is not required, using {code}${project.groupId}{code} instead. Goal is to limit declaration of the group id to the root pom and to the groupId child element in each pom's "parent" element. Changing the groupId then becomes a task analogous to changing the maven version. > 2) Eliminating unnecessary groupId elements where a child pom redundantly declares the groupId inherited from its parent. > 3) Separating groupId elements from version elements by making sure artifactId is in between (rather than before groupId as is currently done in some poms.) This will help avoid spurious conflicts between commits the update the groupId and those that update the version. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3591) Add Elytron Web undertow-servlet module

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3591?page=com.atlassian.jira.plugi... ] Darran Lofthouse moved WFLY-9794 to WFCORE-3591: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-3591 (was: WFLY-9794) Component/s: Security (was: Build System) (was: Security) (was: Web (Undertow)) Fix Version/s: 4.0.0.Beta1 (was: 12.0.0.Alpha1) > Add Elytron Web undertow-servlet module > --------------------------------------- > > Key: WFCORE-3591 > URL: https://issues.jboss.org/browse/WFCORE-3591 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 4.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9794) Add Elytron Web undertow-servlet module

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-9794?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-9794: ----------------------------------- Parent: (was: WFLY-9790) Issue Type: Task (was: Sub-task) > Add Elytron Web undertow-servlet module > --------------------------------------- > > Key: WFLY-9794 > URL: https://issues.jboss.org/browse/WFLY-9794 > Project: WildFly > Issue Type: Task > Components: Build System, Security, Web (Undertow) > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 4.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 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 February 2018