[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
[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
[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
[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
[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, 'D' U+FF24) and use java dialect, DRL build fails with error messages like:
> {noformat}
> line 1:21 no viable alternative at character 'D'
> 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) : D 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
[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, 'D' U+FF24) and use java dialect, DRL build fails with error messages like:
{noformat}
line 1:21 no viable alternative at character 'D'
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) : D 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
[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
[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