October 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-87) Authentication client configuration API

by David Lloyd (JIRA)

David Lloyd created ELY-87: ------------------------------ Summary: Authentication client configuration API Key: ELY-87 URL: https://issues.jboss.org/browse/ELY-87 Project: WildFly Elytron Issue Type: Enhancement Components: API / SPI Reporter: David Lloyd Assignee: David Lloyd Fix For: 1.0.0.Beta1 The base implementation of the Elytron authentication client programmatic API. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-65) Verify client dependencies are minimal

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-65?page=com.atlassian.jira.plugin.sys... ] David Lloyd updated ELY-65: --------------------------- Summary: Verify client dependencies are minimal (was: Verify client decencies are minimal) > Verify client dependencies are minimal > -------------------------------------- > > Key: ELY-65 > URL: https://issues.jboss.org/browse/ELY-65 > Project: WildFly Elytron > Issue Type: Task > Reporter: Darran Lofthouse > Fix For: 1.0.0.Beta1 > > > i.e. don't bring in all of Elytron -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-258) drools-camel-server and guvnor-webapp: Do not use the dependency cxf-bundle-jaxrs because it's an uber jar that disrupts our dependency graph

by Geoffrey De Smet (JIRA)

[ https://issues.jboss.org/browse/DROOLS-258?page=com.atlassian.jira.plugin... ] Geoffrey De Smet commented on DROOLS-258: ----------------------------------------- New requirements: - remove cxf-bundle-* jars from our dep tree, they are evil. - Submit PR to ip-bom to ban them with this enforcer rule: http://maven.apache.org/enforcer/enforcer-rules/bannedDependencies.html > drools-camel-server and guvnor-webapp: Do not use the dependency cxf-bundle-jaxrs because it's an uber jar that disrupts our dependency graph > --------------------------------------------------------------------------------------------------------------------------------------------- > > Key: DROOLS-258 > URL: https://issues.jboss.org/browse/DROOLS-258 > Project: Drools > Issue Type: Bug > Reporter: Geoffrey De Smet > Assignee: Michael Biarnes Kiefer > Priority: Critical > > cxf-bundle-jaxrs isn't mentioned in here: > http://cxf.apache.org/docs/using-cxf-with-maven.html > it pulls in a lot we don't need and we try to exclude what we don't need (but fail at it). > Furher proof that cxf-bundle-jaxrs is evil: > http://svn.apache.org/repos/asf/cxf/trunk/distribution/bundle/jaxrs/pom.xml > It uses the maven-shade-plugin, which is a blocker for the Red Hat re-packers team (see fosdem 2011 presentation) -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1887) Remove the synchronization on JChannel.class in JChannel.init

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1887?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1887: --------------------------- Fix Version/s: 3.6 > Remove the synchronization on JChannel.class in JChannel.init > ------------------------------------------------------------- > > Key: JGRP-1887 > URL: https://issues.jboss.org/browse/JGRP-1887 > Project: JGroups > Issue Type: Task > Affects Versions: 3.5.1 > Reporter: Dan Berindei > Assignee: Bela Ban > Fix For: 3.5.2, 3.6 > > > {{JChannel.init(ProtocolCtackConfigurator)}} has a {{synchronized(Channel.class)}} block that doesn't seem necessary, as JChannel instances do not normally share resources. > This can cause serious delays in the Infinispan test suite, because we run many tests in parallel, each creating its own cluster. In some tests we also have a timeout for the test to create the JChannel (among other things), and these delays can lead to random failures (e.g. ISPN-4802). -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1887) Remove the synchronization on JChannel.class in JChannel.init

by Dan Berindei (JIRA)

Dan Berindei created JGRP-1887: ---------------------------------- Summary: Remove the synchronization on JChannel.class in JChannel.init Key: JGRP-1887 URL: https://issues.jboss.org/browse/JGRP-1887 Project: JGroups Issue Type: Task Affects Versions: 3.5.1 Reporter: Dan Berindei Assignee: Bela Ban Fix For: 3.5.2 {{JChannel.init(ProtocolCtackConfigurator)}} has a {{synchronized(Channel.class)}} block that doesn't seem necessary, as JChannel instances do not normally share resources. This can cause serious delays in the Infinispan test suite, because we run many tests in parallel, each creating its own cluster. In some tests we also have a timeout for the test to create the JChannel (among other things), and these delays can lead to random failures (e.g. ISPN-4802). -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3933) Controller is not available using https-remoting protocol

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-3933?page=com.atlassian.jira.plugin.... ] Darran Lofthouse resolved WFLY-3933. ------------------------------------ Fix Version/s: 9.0.0.Beta1 Resolution: Rejected Please use the forums not Jira for requests for assistance. In general I recommend starting at http://wildfly.org/ to find the appropriate location to ask someone for help. > Controller is not available using https-remoting protocol > --------------------------------------------------------- > > Key: WFLY-3933 > URL: https://issues.jboss.org/browse/WFLY-3933 > Project: WildFly > Issue Type: Feature Request > Components: CLI > Environment: I am trying to deploy my war archive on 8.0.0 final jboss redhat RPM. Everything was working fine until I tried to enable my security options. I have added both <ssl> tag and <trustore> tag under SecurityRealm. In addition I added an <https-listener> and enabled the https-management console. > I've added a controller to jboss-cli.xml as follows: > <controllers> > <controller name="MyHttpsController"> > <protocol>https-remoting</protocol> > <host>myHost</host> > <port>myPort</port> > </controller> > </controllers> > I'm executing the jboss server process by runnning the standalone.sh script and then I'm trying to deploy my war by using the following line: > ./jboss-cli.sh --connect=MyHttpsController command="deploy [myWarPath]" > I get the following error: > The controller is not available at myIp:myPort: java.net.ConnectException: .....The connection timed out > I can open the https-management console via the browser and I checked that my server is actually listening to this port. Please help my if you can, this is very important. > I appreciate all help you can give me. > Thanks all, Michael > Reporter: Michael Sherman > Assignee: Darran Lofthouse > Fix For: 9.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3933) Controller is not available using https-remoting protocol

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-3933?page=com.atlassian.jira.plugin.... ] Darran Lofthouse reassigned WFLY-3933: -------------------------------------- Assignee: Darran Lofthouse (was: Alexey Loubyansky) > Controller is not available using https-remoting protocol > --------------------------------------------------------- > > Key: WFLY-3933 > URL: https://issues.jboss.org/browse/WFLY-3933 > Project: WildFly > Issue Type: Feature Request > Components: CLI > Environment: I am trying to deploy my war archive on 8.0.0 final jboss redhat RPM. Everything was working fine until I tried to enable my security options. I have added both <ssl> tag and <trustore> tag under SecurityRealm. In addition I added an <https-listener> and enabled the https-management console. > I've added a controller to jboss-cli.xml as follows: > <controllers> > <controller name="MyHttpsController"> > <protocol>https-remoting</protocol> > <host>myHost</host> > <port>myPort</port> > </controller> > </controllers> > I'm executing the jboss server process by runnning the standalone.sh script and then I'm trying to deploy my war by using the following line: > ./jboss-cli.sh --connect=MyHttpsController command="deploy [myWarPath]" > I get the following error: > The controller is not available at myIp:myPort: java.net.ConnectException: .....The connection timed out > I can open the https-management console via the browser and I checked that my server is actually listening to this port. Please help my if you can, this is very important. > I appreciate all help you can give me. > Thanks all, Michael > Reporter: Michael Sherman > Assignee: Darran Lofthouse > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3933) Controller is not available using https-remoting protocol

by Michael Sherman (JIRA)

Michael Sherman created WFLY-3933: ------------------------------------- Summary: Controller is not available using https-remoting protocol Key: WFLY-3933 URL: https://issues.jboss.org/browse/WFLY-3933 Project: WildFly Issue Type: Feature Request Components: CLI Environment: I am trying to deploy my war archive on 8.0.0 final jboss redhat RPM. Everything was working fine until I tried to enable my security options. I have added both <ssl> tag and <trustore> tag under SecurityRealm. In addition I added an <https-listener> and enabled the https-management console. I've added a controller to jboss-cli.xml as follows: <controllers> <controller name="MyHttpsController"> <protocol>https-remoting</protocol> <host>myHost</host> <port>myPort</port> </controller> </controllers> I'm executing the jboss server process by runnning the standalone.sh script and then I'm trying to deploy my war by using the following line: ./jboss-cli.sh --connect=MyHttpsController command="deploy [myWarPath]" I get the following error: The controller is not available at myIp:myPort: java.net.ConnectException: .....The connection timed out I can open the https-management console via the browser and I checked that my server is actually listening to this port. Please help my if you can, this is very important. I appreciate all help you can give me. Thanks all, Michael Reporter: Michael Sherman Assignee: Alexey Loubyansky -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-43) Clean up Base64

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-43?page=com.atlassian.jira.plugin.sys... ] Darran Lofthouse commented on ELY-43: ------------------------------------- FYI I believe Undertow already contains a forked implementation of this class - if we were able to adopt it within Elytron it does mean when we add a dependency on Elytron from Undertow we can remove one further Base64 fork. > Clean up Base64 > --------------- > > Key: ELY-43 > URL: https://issues.jboss.org/browse/ELY-43 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Utils > Reporter: Darran Lofthouse > Assignee: Farah Juma > Fix For: 1.0.0.Beta1 > > > The Base64 implementation has been split out of PasswordUtils some additional steps are needed to finish cleaning it up: - > - Look at switching to input and output streams instead of the custom iterators it is using. > - Consider the ByteStringBuilder from SASL > - As potentially more visible ensure clearer method names. > - Ensure adequate javadoc and cross referencing of standards supported. > e.g. If we implement an RFC ensure the number is referenced. > - Testing of each variant > - Consider optional support, e.g. decoding a padded String > - Go beyond testing we can decode what we encode and ensure pre-encoded values can be handled adequately. > Any other clean up here that seems relevant. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-83) EAR deployment overlay did not work if there is no related resource included in the ear

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-83?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFCORE-83: ----------------------------------------------- baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1055229|https://bugzilla.redhat.com/show_bug.cgi?id=1055229] from ASSIGNED to MODIFIED > EAR deployment overlay did not work if there is no related resource included in the ear > --------------------------------------------------------------------------------------- > > Key: WFCORE-83 > URL: https://issues.jboss.org/browse/WFCORE-83 > Project: WildFly Core > Issue Type: Bug > Reporter: Wolf-Dieter Fink > Assignee: Stuart Douglas > Fix For: 1.0.0.Alpha6 > > Attachments: reproducer.zip > > > It is possible to overlay WEB-inf/lib/xy.jar without having xy.jar included in the war file. > If an EAR file is used a module in the lib directory can not be added in the same way. But overlay is working if the lib/xy.jar is available. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 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 2014