June 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-567) Add a builder API for X.509 certificates

by David Lloyd (JIRA)

David Lloyd created ELY-567: ------------------------------- Summary: Add a builder API for X.509 certificates Key: ELY-567 URL: https://issues.jboss.org/browse/ELY-567 Project: WildFly Elytron Issue Type: Feature Request Components: X.500 Reporter: David Lloyd It is going to be somewhat common for us to generate certificates for various purposes, including (but not limited to) self-signing and CSRs. While it is possible to assemble a certificate by hand using the DER encoding API, it would be nicer to have a certificate builder API which wraps the DER encoder and makes this process easier. It should adhere to all certificate generation rules and recommendations found in RFCs and elsewhere. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2591) CLI can not connect to the server started with port-offset

by Liudmila Dobriakova (JIRA)

[ https://issues.jboss.org/browse/WFLY-2591?page=com.atlassian.jira.plugin.... ] Liudmila Dobriakova commented on WFLY-2591: ------------------------------------------- i'm also facing the problem shutting down the jboss. I used the offset 10 to run WildFly to do not come into port conflict with Tomcat, but now i can't shut it down. I tryed also the suggestion sudo ./jboss-cli.sh --connect --controller=remoting://my_alias.com:10000 --command=:shutdown --timeout=10000 but i'm getting the org.jboss.as.cli.CliInitializationException: Failed to connect to the controller. I can still see the management console on browser on the port 10000. Any suggestion? i'm using the wildfly-8.1.0.Final installation with jbpm 6.0 release. Thanks a lot in advance! > CLI can not connect to the server started with port-offset > ---------------------------------------------------------- > > Key: WFLY-2591 > URL: https://issues.jboss.org/browse/WFLY-2591 > Project: WildFly > Issue Type: Sub-task > Components: CLI > Affects Versions: 8.0.0.Beta1, 8.0.0.Final > Environment: used actual WildFly Beta from github: > commit 96160520ce245d6a85cbb77cad92a021564aa376 > Date: Wed Nov 20 17:05:00 2013 +0100 > Reporter: Wolf-Dieter Fink > Assignee: Darran Lofthouse > Fix For: 8.0.0.Final > > > If a standalone server is started with a binding port-offset it is not possible to connect to the native management interface. > To reproduce start a WildFly Beta server (Alpha3 has the same problem) > bin/standalone.sh -Djboss.socket.binding.port-offset=100 > and a cli client: > bin/jboss-cli.sh -c --controller=localhost:10099 > It makes no difference whether the port is changed by port-offset or configuration. > All other ports (i.e. 10090 8180) can be used correct for http-management or ejb invocation. > The server log an ERROR message: > ERROR [org.jboss.remoting.remote.connection] (Remoting "home:MANAGEMENT" I/O-1) JBREM000200: Remote connection failed: java.io.IOException: XNIO000804: Received an invalid message length of 1195725856 > The jboss-cli.sh client show: > org.jboss.as.cli.CliInitializationException: Failed to connect to the controller > at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:240) > at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:218) > 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:292) > at org.jboss.modules.Main.main(Main.java:455) > Caused by: org.jboss.as.cli.CommandLineException: The controller is not available at localhost:10099 > at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:960) > at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:790) > at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:772) > at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:238) > ... 8 more > Caused by: java.io.IOException: java.net.ConnectException: JBAS012174: Could not connect to http-remoting://localhost:10099. The connection failed > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:129) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71) > at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:938) > ... 11 more > Caused by: java.net.ConnectException: JBAS012174: Could not connect to http-remoting://localhost:10099. The connection failed > at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:129) > at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:256) > at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70) > at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:204) > at org.jboss.as.cli.impl.CLIModelControllerClient.getOrCreateChannel(CLIModelControllerClient.java:166) > at org.jboss.as.cli.impl.CLIModelControllerClient$2.getChannel(CLIModelControllerClient.java:127) > at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:117) > at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:92) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127) > ... 13 more > Caused by: java.io.EOFException: XNIO000812: Connection closed unexpectedly > at org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener.handleEvent(HttpUpgrade.java:283) > at org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener.handleEvent(HttpUpgrade.java:266) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) > at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:528) > at ...asynchronous invocation...(Unknown Source) > at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:272) > at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:253) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:351) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:339) > at org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:80) > at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:99) > ... 23 more -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-566) Investigate Elytron and SSSD integration

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-566: ------------------------------------ Summary: Investigate Elytron and SSSD integration Key: ELY-566 URL: https://issues.jboss.org/browse/ELY-566 Project: WildFly Elytron Issue Type: Feature Request Components: Realms Reporter: Darran Lofthouse Fix For: 2.0.0.Alpha1 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-283) Investigate Elytron and gssproxy interoperability

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-283?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-283: --------------------------------- Fix Version/s: 2.0.0.Alpha1 > Investigate Elytron and gssproxy interoperability > ------------------------------------------------- > > Key: ELY-283 > URL: https://issues.jboss.org/browse/ELY-283 > Project: WildFly Elytron > Issue Type: Task > Components: SASL > Reporter: Peter Skopek > Assignee: Peter Skopek > Fix For: 2.0.0.Alpha1 > > > Investigate Elytron and gssproxy interoperability. > https://fedorahosted.org/gss-proxy/ -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1582) Upgrade XNIO to 3.4.x series

by David Lloyd (JIRA)

David Lloyd created WFCORE-1582: ----------------------------------- Summary: Upgrade XNIO to 3.4.x series Key: WFCORE-1582 URL: https://issues.jboss.org/browse/WFCORE-1582 Project: WildFly Core Issue Type: Component Upgrade Reporter: David Lloyd Assignee: David Lloyd Lockless IoFuture implementation should free us from various kinds of deadlocks. Assuming it does not introduce some new problem. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (LOGTOOL-109) Create @NotNull or @RequiresNonNull annotation to allow null checks with custom exception

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/LOGTOOL-109?page=com.atlassian.jira.plugi... ] David Lloyd commented on LOGTOOL-109: ------------------------------------- I disagree with this one. We don't need a proliferation of null check methods; in fact everyone should be using Assert.checkNullParam from wildfly-common for this. > Create @NotNull or @RequiresNonNull annotation to allow null checks with custom exception > ----------------------------------------------------------------------------------------- > > Key: LOGTOOL-109 > URL: https://issues.jboss.org/browse/LOGTOOL-109 > Project: Log Tool > Issue Type: Feature Request > Reporter: James Perkins > > Use an {{@NotNull}} or {{@RequiresNonNull}} annotation on a method to generate a {{null}} check and throw, by default, an {{IllegalArgumentException}} if null. Also clean the stack trace. > {code:java|title=Example Interface} > @Message(id = 123, value = "Name cannot be null") > @NotNull(IllegalArgumentException.class) > void requireNotNull(String name); > {code} > {code:java|title=Example Generated Code} > @Override > public void requireNotNull(final String name) { > if (name == null) { > final IllegalArgumentException result = new IllegalArgumentException(String.format(invalidUser$str(), name)); > final StackTraceElement[] st = result.getStackTrace(); > result.setStackTrace(Arrays.copyOfRange(st, 1, st.length)); > } > } > {code} > The {{@Param}} annotation could be used along with {{@Pos}} for formatting possibly. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1200) Multibyte bind variable name fails with java dialect

by Toshiya Kobayashi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1200?page=com.atlassian.jira.plugi... ] Toshiya Kobayashi commented on DROOLS-1200: ------------------------------------------- Unit test was sent as PR. With a debugger, I observed that NoViableAltException was thrown in JavaLexer.mTokens() so I guess multibyte chars are not considered in java.g. > Multibyte bind variable name fails with java dialect > ---------------------------------------------------- > > Key: DROOLS-1200 > URL: https://issues.jboss.org/browse/DROOLS-1200 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.4.0.Final > Reporter: Toshiya Kobayashi > Assignee: Mario Fusco > > If you have a bind variable which name is multibyte (for example, 'Ｄ' U+FF24) and use java dialect, DRL build fails with error messages like: > {noformat} > line 1:21 no viable alternative at character 'Ｄ' > 18:21:54.036 [main] ERROR o.d.c.k.b.impl.AbstractKieModule.buildKnowledgePackages:249 - Unable to build KieBaseModel:defaultKieBase > Rule Compilation error : [Rule name='R'] > defaultpkg/Rule_R1623499031.java (7:346) : Ｄ cannot be resolved > {noformat} > Mvel dialect doesn't have this issue. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1200) Multibyte bind variable name fails with java dialect

by Toshiya Kobayashi (JIRA)

Toshiya Kobayashi created DROOLS-1200: ----------------------------------------- Summary: Multibyte bind variable name fails with java dialect Key: DROOLS-1200 URL: https://issues.jboss.org/browse/DROOLS-1200 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 6.4.0.Final Reporter: Toshiya Kobayashi Assignee: Mario Fusco If you have a bind variable which name is multibyte (for example, 'Ｄ' U+FF24) and use java dialect, DRL build fails with error messages like: {noformat} line 1:21 no viable alternative at character 'Ｄ' 18:21:54.036 [main] ERROR o.d.c.k.b.impl.AbstractKieModule.buildKnowledgePackages:249 - Unable to build KieBaseModel:defaultKieBase Rule Compilation error : [Rule name='R'] defaultpkg/Rule_R1623499031.java (7:346) : Ｄ cannot be resolved {noformat} Mvel dialect doesn't have this issue. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2077) ExtendedUUID: add superclass which contains only an int

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2077?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-2077. ---------------------------- Resolution: Done Added {{FlagsUUID}} (extending {{UUID}}) from which {{ExtendedUUID}} extends > ExtendedUUID: add superclass which contains only an int > ------------------------------------------------------- > > Key: JGRP-2077 > URL: https://issues.jboss.org/browse/JGRP-2077 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0 > > > ExtendedUUID contains {{flags}} (a short) and arrays of keys and values (byte[] buffers). If someone didn't want the 2 arrays, they'd still pay the cost. > Therefore add a subclass of UUID which contains the {{flags}} (an int) field and make ExtendedUUID subclass it and add the arrays. This way, people can choose which one to use. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6402) EJBs accessible too early (spec violation)

by Fedor Gavrilov (JIRA)

[ https://issues.jboss.org/browse/WFLY-6402?page=com.atlassian.jira.plugin.... ] Fedor Gavrilov resolved WFLY-6402. ---------------------------------- Resolution: Done > EJBs accessible too early (spec violation) > ------------------------------------------ > > Key: WFLY-6402 > URL: https://issues.jboss.org/browse/WFLY-6402 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 10.0.0.Final > Reporter: Brad Maxwell > Assignee: Fedor Gavrilov > Labels: downstream_dependency > Attachments: auto-test-reproducer.zip > > > {code} > EJB 3.1 spec, section 4.8.1: > "If the Startup annotation appears on the Singleton bean class or if the Singleton has been designated via the deployment descriptor as requiring eager initialization, the container must initialize the Singleton bean instance during the application startup sequence. The container must initialize all such startup-time Singletons before any external client requests (that is, client requests originating outside of the application) are delivered to any enterprise bean components in the application. > {code} > Wildlfy does not implement this correctly, and allows calls to other EJBs before a @Startup @Singleton finishes its @PostConstruct call. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 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 June 2016