April 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-1279) Logging MBeans should use java.lang.management.PlatformLoggingMXBean

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFLY-1279?page=com.atlassian.jira.plugin.... ] James Perkins updated WFLY-1279: -------------------------------- Summary: Logging MBeans should use java.lang.management.PlatformLoggingMXBean (was: Logging MBeans have references to a changed when moving to JDK 7) > Logging MBeans should use java.lang.management.PlatformLoggingMXBean > -------------------------------------------------------------------- > > Key: WFLY-1279 > URL: https://issues.jboss.org/browse/WFLY-1279 > Project: WildFly > Issue Type: Task > Components: JMX > Reporter: James Perkins > Assignee: James Perkins > Priority: Minor > > See {{PlatformLoggingMXBeanAttributeHandler}} for an example. These should probably be reviewed for logging changes as well. > The note: > {code} > Implementation note: This implementation uses indirect access to the mbean (i.e. via the > {@code MBeanServerConnection} API) in order to avoid adding a compile time dependency on JDK 7. If the base > JDK requirement for JBoss AS ever moves to JDK 7, this implementation can be updated to use the > {@code java.lang.management.PlatformLoggingMXBean} interface. > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1279) Logging MBeans have references to a changed when moving to JDK 7

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFLY-1279?page=com.atlassian.jira.plugin.... ] James Perkins updated WFLY-1279: -------------------------------- Description: See {{PlatformLoggingMXBeanAttributeHandler}} for an example. These should probably be reviewed for logging changes as well. The note: Implementation note: This implementation uses indirect access to the mbean (i.e. via the * {@code MBeanServerConnection} API) in order to avoid adding a compile time dependency on JDK 7. If the base * JDK requirement for JBoss AS ever moves to JDK 7, this implementation can be updated to use the * {@code java.lang.management.PlatformLoggingMXBean} interface. was:See {{PlatformLoggingMXBeanAttributeHandler}} for an example. These should probably be reviewed for logging changes as well. > Logging MBeans have references to a changed when moving to JDK 7 > ---------------------------------------------------------------- > > Key: WFLY-1279 > URL: https://issues.jboss.org/browse/WFLY-1279 > Project: WildFly > Issue Type: Task > Components: JMX > Reporter: James Perkins > Assignee: James Perkins > Priority: Minor > > See {{PlatformLoggingMXBeanAttributeHandler}} for an example. These should probably be reviewed for logging changes as well. > The note: > Implementation note: This implementation uses indirect access to the mbean (i.e. via the > * {@code MBeanServerConnection} API) in order to avoid adding a compile time dependency on JDK 7. If the base > * JDK requirement for JBoss AS ever moves to JDK 7, this implementation can be updated to use the > * {@code java.lang.management.PlatformLoggingMXBean} interface. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1279) Logging MBeans have references to a changed when moving to JDK 7

by James Perkins (JIRA)

James Perkins created WFLY-1279: ----------------------------------- Summary: Logging MBeans have references to a changed when moving to JDK 7 Key: WFLY-1279 URL: https://issues.jboss.org/browse/WFLY-1279 Project: WildFly Issue Type: Task Components: JMX Reporter: James Perkins Assignee: James Perkins Priority: Minor See {{PlatformLoggingMXBeanAttributeHandler}} for an example. These should probably be reviewed for logging changes as well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-939) Class-Path manifest entries for WARs-in-EAR not handled properly

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-939?page=com.atlassian.jira.plugin.s... ] Stuart Douglas resolved WFLY-939. --------------------------------- Fix Version/s: 8.0.0.Alpha1 Resolution: Done > Class-Path manifest entries for WARs-in-EAR not handled properly > ---------------------------------------------------------------- > > Key: WFLY-939 > URL: https://issues.jboss.org/browse/WFLY-939 > Project: WildFly > Issue Type: Bug > Components: Server > Reporter: James Livingston > Assignee: Stuart Douglas > Fix For: 8.0.0.Alpha1 > > > ManifestClassPathProcessor handles the processing of Class-Path entries in deployments. The handling of those entries in sub-deployments is broken. > https://github.com/doctau/examples/tree/master/war-manifest-classpath builds an EAR containing a utility JAR and two WARs, where both WARs refer to the jar via Class-Path manifest headers. The jar is not in the EAR's library directory nor in application.xml > The resulting module setup will result in the jar being added to the first WAR's module, and the remaining WAR(s) depending on a separate "jar classloader". All WARs should depend on the single shared jar classloader. > When ManifestClassPathProcessor.handlingExistingClassPathEntry() runs for the first war, it will call createAdditionalModule(), which calls createResourceRoot(). The "deploymentUnit.addToAttachmentList(Attachments.RESOURCE_ROOTS, resourceRoot)" adds it to the resource roots for that WAR. > When handlingExistingClassPathEntry() runs for the second (and subsequent) WAR, it will already be in the additionalModules list, so "target.addToAttachmentList(Attachments.CLASS_PATH_ENTRIES, moduleSpecification.getModuleIdentifier())" gets run. > I believe the step of adding it to the CLASS_PATH_ENTRIES attachment needs to happen on the first WAR (so it is added as a module dependency), and it should not be added to the DU RESOURCE_ROOTS so it is not in the WAR's own classloader. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1094) Use own JSSE Provider for http Connector

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-1094?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-1094: ------------------------------ Fix Version/s: 8.0.0.Alpha1 > Use own JSSE Provider for http Connector > ---------------------------------------- > > Key: WFLY-1094 > URL: https://issues.jboss.org/browse/WFLY-1094 > Project: WildFly > Issue Type: Feature Request > Components: Web (JBoss Web) > Affects Versions: 8.0.0.Alpha1 > Reporter: Hauke Mehrtens > Assignee: Tomaz Cerar > Labels: https, jsse, ssl > Fix For: 8.0.0.Alpha1 > > Attachments: ssl-protocol.patch > > > We are using our own JSSE Provider implementation for TLS to add support for HTTPS with preshared key to one http connector, while the others still use the default JSSE provider. > In JBoss 5 we added sslProtocol="RFC4279", while RFC4279 is the name of our provider, to one Connector entry in the file server/default/deploy/jbossweb.sar/server.xml. This option is not available in JBoss 7.1 any more and we could not find a way to make one connector use our provider while the others are using the default one. > To fix this issue for use we used the attached patch. We would like to get this patch into the next version of JBoss, so we do not have to modify the source code by our self any more. This patch was tested with JBoss 7.1.2, but it still applies against the master branch. If we should do any changed to the patch or if you want to get it in an other form please inform us. > With this patch we are able to specify our JSSE provider like this: > {code:xml} > <connector name="httpspsk" protocol="HTTP/1.1" scheme="https" socket-binding="httpspsk" secure="true"> > <ssl name="ssl" key-alias="intended purpose ssl test from bremen online services" password="123456" certificate-key-file="${jboss.server.config.dir}/governikus_ssl.jks" protocol="ALL" keystore-type="JKS" ssl_protocol="RFC4279"/> > </connector> > {code} > This is related to Red Hat Customer Portal support case 00721624 "Additional JSSE Provider on socket bindings and connectors" -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1278) Upgrade HornetQ to 2.3.0.Final

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1278?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-1278: ----------------------------------------------- Jason T. Greene <jason.greene(a)redhat.com> made a comment on [bug 956278|https://bugzilla.redhat.com/show_bug.cgi?id=956278] This is missing acks because the bugzilla bot is once again breaking our issues. I am going to assume its ackd > Upgrade HornetQ to 2.3.0.Final > ------------------------------ > > Key: WFLY-1278 > URL: https://issues.jboss.org/browse/WFLY-1278 > Project: WildFly > Issue Type: Component Upgrade > Components: JMS > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 8.0.0.Alpha1 > > > HornetQ 2.3.0.Final depends on Netty 3.6.2.Final which is the version in WildFly (no need to also upgrade Netty) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBEE-127) Java EE Connector Architecture (JSR-322)

by Shelly McGowan (JIRA)

[ https://issues.jboss.org/browse/JBEE-127?page=com.atlassian.jira.plugin.s... ] Shelly McGowan commented on JBEE-127: ------------------------------------- Need to update source header files prior to the release as well. > Java EE Connector Architecture (JSR-322) > ---------------------------------------- > > Key: JBEE-127 > URL: https://issues.jboss.org/browse/JBEE-127 > Project: JBoss JavaEE Spec APIs > Issue Type: Sub-task > Components: jboss-connector-api > Reporter: Shelly McGowan > Assignee: Shelly McGowan > Fix For: JavaEE 7 Spec APIs 1.0.0.Beta1 > > > Project repo exists: > https://github.com/jboss/jboss-connector-api_spec > Need updates to for v1.7. > {code} > <groupId>org.jboss.spec.javax.resource</groupId> > <artifactId>jboss-connector-api_1.7_spec</artifactId> > <version>1.0.0-SNAPSHOT</version> > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1094) Use own JSSE Provider for http Connector

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1094?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-1094: ----------------------------------------------- Hauke Mehrtens <hauke(a)hauke-m.de> made a comment on [bug 956391|https://bugzilla.redhat.com/show_bug.cgi?id=956391] Some of our costumers are using JBoss EAP and our application needs the TLS cipher suite TLS_RSA_PSK_WITH_AES_128_CBC_SHA, which we implemented in an own security provider. This special TLS cipher suite is only used for a special dedicated connection and the application server has to talk "normal" ssl on other ports at the same time. In JBoss EAP 5 we added sslProtocol="RFC4279", while RFC4279 is the name of our provider, to one Connector entry in the file server/default/deploy/jbossweb.sar/server.xml. This option is not available in JBoss EAP 6 any more and we could not find a way to make one connector use our provider while the others are using the default one. To fix this issue for use we used the attached patch. We would like to get this patch into the next version of the JBoss EAP 6.X branch, so we do not have to modify the source code by our self any more. This patch was tested with JBoss EAP 6.0.0. Currently we patched the source code of the corresponding community edition and replaced the jboss-web jar with our patched jar in the community and EAP version. With this patch we are able to specify our JSSE provider like this: <connector name="httpspsk" protocol="HTTP/1.1" scheme="https" socket-binding="httpspsk" secure="true"> <ssl name="ssl" key-alias="intended purpose ssl test from bremen online services" password="123456" certificate-key-file="${jboss.server.config.dir}/governikus_ssl.jks" protocol="ALL" keystore-type="JKS" ssl_protocol="RFC4279"/> </connector> This is related to Red Hat Customer Portal support case 00721624 "Additional JSSE Provider on socket bindings and connectors" > Use own JSSE Provider for http Connector > ---------------------------------------- > > Key: WFLY-1094 > URL: https://issues.jboss.org/browse/WFLY-1094 > Project: WildFly > Issue Type: Feature Request > Components: Web (JBoss Web) > Affects Versions: 8.0.0.Alpha1 > Reporter: Hauke Mehrtens > Assignee: Tomaz Cerar > Labels: https, jsse, ssl > Attachments: ssl-protocol.patch > > > We are using our own JSSE Provider implementation for TLS to add support for HTTPS with preshared key to one http connector, while the others still use the default JSSE provider. > In JBoss 5 we added sslProtocol="RFC4279", while RFC4279 is the name of our provider, to one Connector entry in the file server/default/deploy/jbossweb.sar/server.xml. This option is not available in JBoss 7.1 any more and we could not find a way to make one connector use our provider while the others are using the default one. > To fix this issue for use we used the attached patch. We would like to get this patch into the next version of JBoss, so we do not have to modify the source code by our self any more. This patch was tested with JBoss 7.1.2, but it still applies against the master branch. If we should do any changed to the patch or if you want to get it in an other form please inform us. > With this patch we are able to specify our JSSE provider like this: > {code:xml} > <connector name="httpspsk" protocol="HTTP/1.1" scheme="https" socket-binding="httpspsk" secure="true"> > <ssl name="ssl" key-alias="intended purpose ssl test from bremen online services" password="123456" certificate-key-file="${jboss.server.config.dir}/governikus_ssl.jks" protocol="ALL" keystore-type="JKS" ssl_protocol="RFC4279"/> > </connector> > {code} > This is related to Red Hat Customer Portal support case 00721624 "Additional JSSE Provider on socket bindings and connectors" -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1094) Use own JSSE Provider for http Connector

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1094?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-1094: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=956391 > Use own JSSE Provider for http Connector > ---------------------------------------- > > Key: WFLY-1094 > URL: https://issues.jboss.org/browse/WFLY-1094 > Project: WildFly > Issue Type: Feature Request > Components: Web (JBoss Web) > Affects Versions: 8.0.0.Alpha1 > Reporter: Hauke Mehrtens > Assignee: Tomaz Cerar > Labels: https, jsse, ssl > Attachments: ssl-protocol.patch > > > We are using our own JSSE Provider implementation for TLS to add support for HTTPS with preshared key to one http connector, while the others still use the default JSSE provider. > In JBoss 5 we added sslProtocol="RFC4279", while RFC4279 is the name of our provider, to one Connector entry in the file server/default/deploy/jbossweb.sar/server.xml. This option is not available in JBoss 7.1 any more and we could not find a way to make one connector use our provider while the others are using the default one. > To fix this issue for use we used the attached patch. We would like to get this patch into the next version of JBoss, so we do not have to modify the source code by our self any more. This patch was tested with JBoss 7.1.2, but it still applies against the master branch. If we should do any changed to the patch or if you want to get it in an other form please inform us. > With this patch we are able to specify our JSSE provider like this: > {code:xml} > <connector name="httpspsk" protocol="HTTP/1.1" scheme="https" socket-binding="httpspsk" secure="true"> > <ssl name="ssl" key-alias="intended purpose ssl test from bremen online services" password="123456" certificate-key-file="${jboss.server.config.dir}/governikus_ssl.jks" protocol="ALL" keystore-type="JKS" ssl_protocol="RFC4279"/> > </connector> > {code} > This is related to Red Hat Customer Portal support case 00721624 "Additional JSSE Provider on socket bindings and connectors" -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBEE-122) Concurrency Utilities for Java EE (JSR-236)

by Shelly McGowan (JIRA)

[ https://issues.jboss.org/browse/JBEE-122?page=com.atlassian.jira.plugin.s... ] Shelly McGowan resolved JBEE-122. --------------------------------- Resolution: Done Resolving this for now. Will push a .Final release after additional testing. > Concurrency Utilities for Java EE (JSR-236) > -------------------------------------------- > > Key: JBEE-122 > URL: https://issues.jboss.org/browse/JBEE-122 > Project: JBoss JavaEE Spec APIs > Issue Type: Sub-task > Components: jboss-javaee-concurrency-api > Reporter: Shelly McGowan > Assignee: Shelly McGowan > Fix For: JavaEE 7 Spec APIs 1.0.0.Beta1 > > > These APIs are required as part of our Java EE 7 implementation. > They should be added to the org.jboss.spec project: > {code} > <dependency> > <groupId>org.jboss.spec.javax.enterprise.concurrent</groupId> > <artifactId>jboss-concurrent-api_1.0_spec</artifactId> > <version>1.0.0.Final-SNAPSHOT</version> > </dependency> > {code} > Project can be created in http://github.com/jboss/jboss-concurrent-api_spec -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 8 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2013