[JBoss JIRA] (WFCORE-609) Administrator Encouragement
by Darran Lofthouse (JIRA)
Darran Lofthouse created WFCORE-609:
---------------------------------------
Summary: Administrator Encouragement
Key: WFCORE-609
URL: https://issues.jboss.org/browse/WFCORE-609
Project: WildFly Core
Issue Type: Feature Request
Components: Domain Management
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 2.0.0.Alpha1
I know the name is not popular so will have a better name ;-)
Essentially some form of centralised repository to hold warnings raised by subsystems as a server boots.
Management operations would be provided to query the current warnings.
As administrators undertake actions to correct a warning it will be dynamically removed by the subsystem that reported it.
This is not about persistent warnings i.e. the subsystem should raise the warning on every boot and stop raising it if it is no longer relevant.
e.g. SSL not enabled, warn every time the server starts until it is enabled.
Warnings will be associated with a severity level and administrative tooling can decide how pro-actively to display the warning, e.g. the console may pop up immediately for a critical warning or use an icon to indicate the presence of a lesser warning.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-4444) Ability to set WSDL URL
by John Ament (JIRA)
[ https://issues.jboss.org/browse/WFLY-4444?page=com.atlassian.jira.plugin.... ]
John Ament commented on WFLY-4444:
----------------------------------
I'm struggling a bit to make this work using a {{jbossws-cxf.xml}}. I think I can tweak it from there.
I've tried adding the file to my JAR's META-INF as well as the WAR file's WEB-INF, neither seems to be tweaking it. Do I have to do anything special there?
> Ability to set WSDL URL
> -----------------------
>
> Key: WFLY-4444
> URL: https://issues.jboss.org/browse/WFLY-4444
> Project: WildFly
> Issue Type: Feature Request
> Components: Web Services
> Affects Versions: 8.2.0.Final
> Reporter: John Ament
> Assignee: Alessio Soldano
>
> There's no way to correctly set a WSDL URL. The properties are:
> {code}
> <modify-wsdl-address>true</modify-wsdl-address>
> <wsdl-host>${public.app.host:localhost}</wsdl-host>
> <wsdl-port>${public.http.port:80}</wsdl-port>
> <wsdl-secure-port>${public.https.port:443}</wsdl-secure-port>
> {code}
> We need a way to set the WSDL URL, regardless of the protocol used. The issue being that our app servers run on HTTP, but the incoming request to the first load balancer is over HTTPS. The result is that the WSDL generated includes http://public-host:80/ instead of https://public-host:443/
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-4449) Default JNDI bindings should set the server in a reload required state when changed
by James Perkins (JIRA)
James Perkins created WFLY-4449:
-----------------------------------
Summary: Default JNDI bindings should set the server in a reload required state when changed
Key: WFLY-4449
URL: https://issues.jboss.org/browse/WFLY-4449
Project: WildFly
Issue Type: Bug
Components: EE
Reporter: James Perkins
Assignee: James Perkins
When a write operation like {{/subsystem=ee/service=default-bindings:write-attribute(name=datasource,value="java:jboss/datasources/DefaultDS")}} is executed on the default bindings the server is not set into {{reload-required}} state as it should be. The names in the service are also changed. This means new deployments or new lookups could see a different name than was originally configured when the server started.
The other default resource names should also be looked at to ensure they don't override current settings.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (ELY-118) Reloadable File-backed KeyStore
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-118?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse commented on ELY-118:
--------------------------------------
Deferring for the moment, may make more sense to be the responsibility of the subsystem to track this as it needs to be coordinated with the other management requests currently happening - also there is the issue of possible race conditions where the file is modified and also the runtime state is modified so will wait until we really have a better idea once all the management operations are in place.
> Reloadable File-backed KeyStore
> -------------------------------
>
> Key: ELY-118
> URL: https://issues.jboss.org/browse/ELY-118
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: KeyStores
> Reporter: David Lloyd
> Assignee: Darran Lofthouse
> Fix For: 1.0.0.Beta1
>
>
> File-backed keystores can generically be made reloadable. This can be done by creating a KeyStore wrapper which contains an {{AtomicReference<KeyStore>}}. The wrapper also has a file name reference, and will initialize itself from that file. It would use an NIO.2 file watcher to monitor the file for changes; when the file is changed, the watcher attempts to re-load the file into a new KeyStore instance (using cached protection parameters). If successful, the new KeyStore replaces the old one atomically, providing atomic and clean real-time update capability.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (ELY-118) Reloadable File-backed KeyStore
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-118?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-118:
---------------------------------
Fix Version/s: 1.0.0.Beta1
(was: 1.0.0.Alpha1)
> Reloadable File-backed KeyStore
> -------------------------------
>
> Key: ELY-118
> URL: https://issues.jboss.org/browse/ELY-118
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: KeyStores
> Reporter: David Lloyd
> Assignee: Darran Lofthouse
> Fix For: 1.0.0.Beta1
>
>
> File-backed keystores can generically be made reloadable. This can be done by creating a KeyStore wrapper which contains an {{AtomicReference<KeyStore>}}. The wrapper also has a file name reference, and will initialize itself from that file. It would use an NIO.2 file watcher to monitor the file for changes; when the file is changed, the watcher attempts to re-load the file into a new KeyStore instance (using cached protection parameters). If successful, the new KeyStore replaces the old one atomically, providing atomic and clean real-time update capability.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (DROOLS-745) Unnecessary and thread-blocking "synchronized" in MVELSafeHelper.java
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-745?page=com.atlassian.jira.plugin... ]
Mario Fusco resolved DROOLS-745.
--------------------------------
Fix Version/s: 6.3.0.Beta1
Resolution: Done
Fixed by https://github.com/droolsjbpm/drools/commit/1beb00549
> Unnecessary and thread-blocking "synchronized" in MVELSafeHelper.java
> ---------------------------------------------------------------------
>
> Key: DROOLS-745
> URL: https://issues.jboss.org/browse/DROOLS-745
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.2.0.Final
> Reporter: Andrey Bichkevskiy
> Assignee: Mario Fusco
> Labels: drools-core
> Fix For: 6.3.0.Beta1
>
> Original Estimate: 5 minutes
> Remaining Estimate: 5 minutes
>
> Class org.drools.core.util.MVELSafeHelper, obsolete and thread-blocking "synchronized" keyword in static getter of a static final field:
> public class MVELSafeHelper {
> private static final MVELEvaluator evaluator;
> static {
> evaluator = KiePolicyHelper.isPolicyEnabled() ? new SafeMVELEvaluator() : new RawMVELEvaluator();
> }
> public static synchronized MVELEvaluator getEvaluator() {
> return evaluator;
> }
> //
> }
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (SECURITY-784) LdapExtLoginModule cannot find custom ldap socket factory
by Jonhny Jonhny (JIRA)
[ https://issues.jboss.org/browse/SECURITY-784?page=com.atlassian.jira.plug... ]
Jonhny Jonhny commented on SECURITY-784:
----------------------------------------
Do we have any plan complete the fix for java 7?
> LdapExtLoginModule cannot find custom ldap socket factory
> ---------------------------------------------------------
>
> Key: SECURITY-784
> URL: https://issues.jboss.org/browse/SECURITY-784
> Project: PicketBox
> Issue Type: Feature Request
> Components: PicketBox
> Affects Versions: PicketBox_4_0_19.Final
> Reporter: Derek Horton
> Assignee: Stefan Guilhen
> Attachments: SECURITY-784.patch
>
>
> LdapExtLoginModule cannot find custom ldap socket factory.
> Passing the "java.naming.ldap.factory.socket" property in as an
> module-option:
> <module-option name="java.naming.ldap.factory.socket" value="org.jboss.example.CustomSocketFactory"/>
> results in a ClassNotFoundException:
> Caused by: javax.naming.CommunicationException: 192.168.1.8:389 [Root exception is java.lang.ClassNotFoundException: org/jboss/example/CustomSocketFactory]
> at com.sun.jndi.ldap.Connection.<init>(Connection.java:226) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:136) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1608) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2698) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:316) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:193) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:211) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:154) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:84) [rt.jar:1.7.0_45]
> at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684) [rt.jar:1.7.0_45]
> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307) [rt.jar:1.7.0_45]
> at javax.naming.InitialContext.init(InitialContext.java:242) [rt.jar:1.7.0_45]
> at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:153) [rt.jar:1.7.0_45]
> at org.jboss.security.auth.spi.LdapExtLoginModule.constructInitialLdapContext(LdapExtLoginModule.java:767) [picketbox-4.0.17.SP2-redhat-2.jar:4.0.17.SP2-redhat-2]
> I tried making the custom socket factory into a jboss module and adding the module as a dependency to picketbox and
> sun.jdk. Unfortunately, that did not work. I also added the socket
> factory jar to the jre/lib/ext directory. That didn't work either.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (DROOLS-25) Cannot unmarshall large session file: InvalidProtocolBufferException
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-25?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on DROOLS-25:
-----------------------------------------------
Mario Fusco <mfusco(a)redhat.com> changed the Status of [bug 1201785|https://bugzilla.redhat.com/show_bug.cgi?id=1201785] from ASSIGNED to MODIFIED
> Cannot unmarshall large session file: InvalidProtocolBufferException
> --------------------------------------------------------------------
>
> Key: DROOLS-25
> URL: https://issues.jboss.org/browse/DROOLS-25
> Project: Drools
> Issue Type: Bug
> Affects Versions: 5.5.0.Final
> Environment: Jdk 7
> Reporter: Magnus Vojbacke
> Assignee: Edson Tirelli
> Fix For: 5.5.1.Final, 6.0.0.Alpha9
>
>
> When trying to unmarshall a large knowledge session from a file stream, an exception is thrown.
> It seems that there is a default message size limit in Protobuf (used by Drools marshalling). Apparently, what happens is that the marshalled "Header" message exceeds this size, which causes Protobuf to throw this exception.
> I suspect that the Header field "payload" is the culprit, since it seems to contain the rest of the knowledge base in byte array form.
> Here's the stack trace:
> {code:title=Stacktrace}
> com.google.protobuf.InvalidProtocolBufferException: Protocol message was too large. May be malicious. Use CodedInputStream.setSizeLimit() to increase the size limit.
> at com.google.protobuf.InvalidProtocolBufferException.sizeLimitExceeded:89
> at com.google.protobuf.CodedInputStream.refillBuffer:720
> at com.google.protobuf.CodedInputStream.isAtEnd:666
> at com.google.protobuf.CodedInputStream.readTag:99
> at org.drools.marshalling.impl.ProtobufMessages$Header$Builder.mergeFrom:967
> at org.drools.marshalling.impl.ProtobufMessages$Header$Builder.mergeFrom:773
> at com.google.protobuf.AbstractMessageLite$Builder.mergeFrom:212
> at com.google.protobuf.AbstractMessage$Builder.mergeFrom:746
> at org.drools.marshalling.impl.ProtobufMessages$Header.parseFrom:724
> at org.drools.marshalling.impl.PersisterHelper.readFromStreamWithHeader:234
> at org.drools.marshalling.impl.ProtobufInputMarshaller.loadAndParseSession:217
> at org.drools.marshalling.impl.ProtobufInputMarshaller.readSession:107
> at org.drools.marshalling.impl.ProtobufMarshaller.unmarshall:143
> {code}
> Suggested solutions:
> #1
> You can set the size limit of the Protobuf CodedInputStream, but there doesn't seem to be any way of providing this parameter to the Drools unmarshalling API.
> #2
> When you unmarshall from a byte array, Protobuf does not enforce any message size limit. I have successfully implemented a patch in drools-core that preloads the file into memory and unmarshalls from a byte array. Probably the least desirable fix.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-4376) Incorrect callback handler used during authentication (SASL)
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-4376?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-4376:
-----------------------------------------------
Enrique Gonzalez Martinez <egonzale(a)redhat.com> changed the Status of [bug 996897|https://bugzilla.redhat.com/show_bug.cgi?id=996897] from ASSIGNED to CLOSED
> Incorrect callback handler used during authentication (SASL)
> -------------------------------------------------------------
>
> Key: WFLY-4376
> URL: https://issues.jboss.org/browse/WFLY-4376
> Project: WildFly
> Issue Type: Bug
> Reporter: Enrique González Martínez
> Assignee: Enrique González Martínez
>
> Cluster topology messages are not using the proper callbackhandler when the connection is being established.
> {code}
> 06:59:44,609 ERROR [org.jboss.remoting.remote.connection] (Remoting "config-based-ejb-client-endpoint" read-1) JBREM000200: Remote connection failed: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
> 06:59:44,611 INFO [org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager] (ejb-client-cluster-node-connection-creation-2-thread-2) Could not create a connection for cluster node ClusterNode{clusterName='ejb', nodeName='perf18', clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0, sourceNetworkMaskBits=0, destinationAddress='10.16.90.54', destinationPort=4447}], resolvedDestination=[Destination address=10.16.90.54, destination port=4447]} in cluster ejb
> java.lang.RuntimeException: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
> at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:91)
> at org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:89)
> at org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.call(ClusterContext.java:406)
> at org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.call(ClusterContext.java:380)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> Caused by: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:382)
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:225)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
> at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)
> at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
> at org.xnio.nio.NioHandle.run(NioHandle.java:90)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:187)
> at ...asynchronous invocation...(Unknown Source)
> at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:270)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:386)
> at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:151)
> at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:132)
> at org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:87)
> ... 7 more
> {code}
> Before that, this log is produced:
> {code}
> DEBUG: Client authentication failed for mechanism DIGEST-MD5: javax.security.sasl.SaslException: DIGEST-MD5: Cannot perform callback to acquire realm, authentication ID or password [Caused by javax.security.auth.callback.UnsupportedCallbackException]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months