February 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-8136) allow JAX-RS @Produces in CDI @Stereotype

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-8136?page=com.atlassian.jira.plugin.... ] Stuart Douglas reassigned WFLY-8136: ------------------------------------ Assignee: Alessio Soldano (was: Stuart Douglas) > allow JAX-RS @Produces in CDI @Stereotype > ----------------------------------------- > > Key: WFLY-8136 > URL: https://issues.jboss.org/browse/WFLY-8136 > Project: WildFly > Issue Type: Feature Request > Components: CDI / Weld > Affects Versions: 9.0.1.Final > Environment: Windows 7, JDK 1.8.0_60 > Reporter: Andreas Klemp > Assignee: Alessio Soldano > > A simple JAX-RS REST service can be annotated with @Produces to define the resulting mime-type. However, it is not working anymore, when the annotation is moved to a stereotype. The default application/octet-stream is used. > {code} > @Stereotype > @Produces(MediaType.APPLICATION_JSON) > @Target(ElementType.TYPE) > @Retention(RetentionPolicy.RUNTIME) > public @interface RestService { > } > @Path("/some") > @RestService > public class SomeRestService { > @GET > @Path("/") > public Response getSome() { > return Response.ok().entity("{\"x\" : 42, \"y\" : \"foo\"}").build(); > } > } > {code} > Using the following dependencies in Gradle project. > {noformat} > providedCompile( > [group: 'javax.enterprise', name: 'cdi-api', version: '1.2'], > [group: 'org.jboss.spec.javax.ws.rs', name: 'jboss-jaxrs-api_2.0_spec', version: '1.0.0.Final'], > [group: 'com.fasterxml.jackson.core', name: 'jackson-databind', version: '2.7.4'] > ) > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8136) allow JAX-RS @Produces in CDI @Stereotype

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-8136?page=com.atlassian.jira.plugin.... ] Stuart Douglas updated WFLY-8136: --------------------------------- Component/s: REST > allow JAX-RS @Produces in CDI @Stereotype > ----------------------------------------- > > Key: WFLY-8136 > URL: https://issues.jboss.org/browse/WFLY-8136 > Project: WildFly > Issue Type: Feature Request > Components: CDI / Weld, REST > Affects Versions: 9.0.1.Final > Environment: Windows 7, JDK 1.8.0_60 > Reporter: Andreas Klemp > Assignee: Alessio Soldano > > A simple JAX-RS REST service can be annotated with @Produces to define the resulting mime-type. However, it is not working anymore, when the annotation is moved to a stereotype. The default application/octet-stream is used. > {code} > @Stereotype > @Produces(MediaType.APPLICATION_JSON) > @Target(ElementType.TYPE) > @Retention(RetentionPolicy.RUNTIME) > public @interface RestService { > } > @Path("/some") > @RestService > public class SomeRestService { > @GET > @Path("/") > public Response getSome() { > return Response.ok().entity("{\"x\" : 42, \"y\" : \"foo\"}").build(); > } > } > {code} > Using the following dependencies in Gradle project. > {noformat} > providedCompile( > [group: 'javax.enterprise', name: 'cdi-api', version: '1.2'], > [group: 'org.jboss.spec.javax.ws.rs', name: 'jboss-jaxrs-api_2.0_spec', version: '1.0.0.Final'], > [group: 'com.fasterxml.jackson.core', name: 'jackson-databind', version: '2.7.4'] > ) > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8163) Review hard coded of jboss-ejb-policy in EJBComponentDescription.SecurityDomainDependencyConfigurator#configure

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-8163?page=com.atlassian.jira.plugin.... ] Stuart Douglas reassigned WFLY-8163: ------------------------------------ Assignee: Stuart Douglas (was: Darran Lofthouse) > Review hard coded of jboss-ejb-policy in EJBComponentDescription.SecurityDomainDependencyConfigurator#configure > --------------------------------------------------------------------------------------------------------------- > > Key: WFLY-8163 > URL: https://issues.jboss.org/browse/WFLY-8163 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Stuart Douglas > Assignee: Stuart Douglas > > This dep is hard coded because it was required by picketbox, however now that elytron is in we should not be creating picketbox dependencies by default. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8163) Review hard coded of jboss-ejb-policy in EJBComponentDescription.SecurityDomainDependencyConfigurator#configure

by Stuart Douglas (JIRA)

Stuart Douglas created WFLY-8163: ------------------------------------ Summary: Review hard coded of jboss-ejb-policy in EJBComponentDescription.SecurityDomainDependencyConfigurator#configure Key: WFLY-8163 URL: https://issues.jboss.org/browse/WFLY-8163 Project: WildFly Issue Type: Bug Components: Security Reporter: Stuart Douglas Assignee: Darran Lofthouse This dep is hard coded because it was required by picketbox, however now that elytron is in we should not be creating picketbox dependencies by default. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBMETA-393) Missing jboss-web_10_0.xsd on jboss.org

by ebuzer taha kanat (JIRA)

[ https://issues.jboss.org/browse/JBMETA-393?page=com.atlassian.jira.plugin... ] ebuzer taha kanat commented on JBMETA-393: ------------------------------------------ Referenced file contains errors (http://www.jboss.org/schema/jbossas/jboss-web_10_0.xsd) > Missing jboss-web_10_0.xsd on jboss.org > --------------------------------------- > > Key: JBMETA-393 > URL: https://issues.jboss.org/browse/JBMETA-393 > Project: JBoss Metadata > Issue Type: Bug > Components: web > Reporter: Ladislav Thon > Assignee: Jean-Frederic Clere > Priority: Critical > > The {{jboss-web_10_0.xsd}} file we ship with WildFly 10 says at the beginning: > {code:xml} > <jboss-web xmlns="http://www.jboss.com/xml/ns/javaee" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-web_10_0.xsd" > version="10.0"> > ... > </jboss-web> > Instance documents may indicate the published version of > the schema using the xsi:schemaLocation attribute for the > Java EE namespace with the following location: > http://www.jboss.org/j2ee/schema/jboss-web_10_0.xsd > {code} > So we're pointing people to http://www.jboss.org/j2ee/schema/, which is a seemingly arbitrary collection of fairly old files that definitely doesn't contain {{jboss-web_10_0.xsd}}. > This seems to also be the case for XSDs in previously shipped products, e.g. all {{jboss-web_7_*.xsd}} files in EAP 6.4 point to the same location. > I found that http://www.jboss.org/schema/jbossas/ contains a more modern set of XSDs, but: > - we don't point to it, at least not from {{jboss-web_*.xsd}} files > - it doesn't contain {{jboss-web_10_0.xsd}} > I think the second point should be fairly easy to fix. Hope this is not the wrong place to report this :-) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-459) Account for attribute groups in CLI behavior

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-459?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-459: ------------------------------------ Fix Version/s: 3.0.0.Beta4 (was: 3.0.0.Beta3) > Account for attribute groups in CLI behavior > -------------------------------------------- > > Key: WFCORE-459 > URL: https://issues.jboss.org/browse/WFCORE-459 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI > Reporter: Brian Stansberry > Assignee: Jean-Francois Denise > Fix For: 3.0.0.Beta4 > > > See http://lists.jboss.org/pipermail/wildfly-dev/2014-December/003414.html > This JIRA is for reflecting the attribute group notion in CLI behavior. > I think this is just reflecting it in the output of the "ls -l" command, although there may be other places I'm not thinking of. For "ls -l" simplest is just to add a GROUP column to the right, and then sort the attributes by group and then by name, but perhaps something else is better. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-396) Look into whether READ_ONLY but not RUNTIME_ONLY domain server ops should be visible to users

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-396?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-396: ------------------------------------ Fix Version/s: 3.0.0.Beta4 (was: 3.0.0.Beta3) > Look into whether READ_ONLY but not RUNTIME_ONLY domain server ops should be visible to users > --------------------------------------------------------------------------------------------- > > Key: WFCORE-396 > URL: https://issues.jboss.org/browse/WFCORE-396 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Ken Wills > Fix For: 3.0.0.Beta4 > > > Ops registered on a domain server without the RUNTIME_ONLY flag are hidden from users (e.g. in read-operation-names results etc) in order to not delude users into thinking they can do something like :write-attribute directly on a server (instead of modifying host or domain config elements.) > But shouldn't a READ_ONLY flag be sufficient as well? An op that only reads config should be valid. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-266) Deprecate the ParameterValidator constructor variants that accept allowNull and allowExpressions params

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-266?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-266: ------------------------------------ Fix Version/s: 3.0.0.Beta4 (was: 3.0.0.Beta3) > Deprecate the ParameterValidator constructor variants that accept allowNull and allowExpressions params > ------------------------------------------------------------------------------------------------------- > > Key: WFCORE-266 > URL: https://issues.jboss.org/browse/WFCORE-266 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > Fix For: 3.0.0.Beta4 > > > Most of the ParameterValidator implementations that get passed to AttributeDefinition accept params to control whether null and expressions are allowed. These are now redundant, as AttributeDefinition wraps the provided validator with NillableOrExpressionParameterValidator, and it handles that aspect of validation based on the settings of the AD. > So we should deprecate these constructor variants to let people know they aren't needed. Ideally shift the code as well. > CRITICAL: before doing this, make sure the AttributeDefinition variants that support complex types properly wrap any validators that are configured for *element* validation. A quick look shows that ListAttributeDefinition.Builder and MapAttributeDefinition.Builder do. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-644) jboss-cli needs to support using PKCS11 (including FIPS mode) keystores/truststores

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-644?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-644: ------------------------------------ Fix Version/s: 3.0.0.Beta4 (was: 3.0.0.Beta3) > jboss-cli needs to support using PKCS11 (including FIPS mode) keystores/truststores > ----------------------------------------------------------------------------------- > > Key: WFCORE-644 > URL: https://issues.jboss.org/browse/WFCORE-644 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: Derek Horton > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 3.0.0.Beta4 > > > The cli's SSL configuration should be expanded to support using PKCS11 keystores/truststores. Currently it does not appear to be possible to configure the keystore/truststore type in the jboss-cli.xml file. > This is problematic when the JVM is running in FIPS mode. > The cli throws the following exception on startup: > $ ./bin/jboss-cli.sh > org.jboss.as.cli.CliInitializationException: java.security.KeyManagementException: FIPS mode: only SunJSSE TrustManagers may be used > at org.jboss.as.cli.impl.CommandContextImpl.initSSLContext(CommandContextImpl.java:541) > at org.jboss.as.cli.impl.CommandContextImpl.<init>(CommandContextImpl.java:291) > at org.jboss.as.cli.impl.CommandContextFactoryImpl.newCommandContext(CommandContextFactoryImpl.java:76) > at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:294) > at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:277) > at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.jboss.modules.Module.run(Module.java:312) > at org.jboss.modules.Main.main(Main.java:460) > Caused by: java.security.KeyManagementException: FIPS mode: only SunJSSE TrustManagers may be used > at sun.security.ssl.SSLContextImpl.chooseTrustManager(SSLContextImpl.java:126) > at sun.security.ssl.SSLContextImpl.engineInit(SSLContextImpl.java:89) > at javax.net.ssl.SSLContext.init(SSLContext.java:283) > at org.jboss.as.cli.impl.CommandContextImpl.initSSLContext(CommandContextImpl.java:537) > ... 11 more > It is possible to workaround the issue by setting the javax.net.ssl.keyStore / javax.net.ssl.trustStore system properties in the bin/jboss-cli.sh file: > JAVA_OPTS="$JAVA_OPTS -Djavax.net.ssl.trustStore=NONE -Djavax.net.ssl.trustStoreType=PKCS11" > JAVA_OPTS="$JAVA_OPTS -Djavax.net.ssl.keyStore=NONE -Djavax.net.ssl.keyStoreType=PKCS11 -Djavax.net.ssl.keyStorePassword=imapassword" -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-107) Update whoami operation to return authentication mechanism where verbose=true

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-107?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-107: ------------------------------------ Fix Version/s: 3.0.0.Beta4 (was: 3.0.0.Beta3) > Update whoami operation to return authentication mechanism where verbose=true > ----------------------------------------------------------------------------- > > Key: WFCORE-107 > URL: https://issues.jboss.org/browse/WFCORE-107 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta4 > > > The admin console currently contains a "logout" handler that follows a round of HTTP message exchanges to trick the web browser into forgetting the credentials it has cached. > This only makes sense where the browser has cached a credential - if we return the authentication mechanism then the console can make a better decision regarding displaying the logout link or could change the implementation so display a message to the user explaining why logout does not make sense. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 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 2017