[JBoss JIRA] (WFLY-7579) rts integration tests failed when building with jdk 9
by Amos Feng (JIRA)
Amos Feng created WFLY-7579:
-------------------------------
Summary: rts integration tests failed when building with jdk 9
Key: WFLY-7579
URL: https://issues.jboss.org/browse/WFLY-7579
Project: WildFly
Issue Type: Bug
Components: Test Suite, Transactions
Reporter: Amos Feng
Assignee: Amos Feng
It can not start the wildfly with the exception
{code}
Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make protected java.lang.Package java.lang.ClassLoader.getPackage(java.lang.String) accessible: module java.base does not "exports private java.lang" to unnamed module @77e4c80f
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFCORE-1981) Many deprecation warnings in wf-core code
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1981?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1981:
------------------------------------------
I do not particularly like this kind of issue for WildFly Core. It encourages broad based changes affecting random areas.
Any changes made for this must come in discrete chunks, one PR per chunk, with only conceptually related changes in any one chunk. Any wide ranging PRs will be rejected.
This JIRA must not be used as justification for eliminating deprecated classes/methods (and thus eliminating required use of them, e.g. in wrapper classes.) Any such change will be rejected. If some deprecated class/method should be eliminated it needs to be done under a separate issue.
Until the JDK provides something like @Experimental/@Unstable that functions like @Deprecated it is not a goal to eliminate all deprecated API usage in core. We sometimes use @Deprecated as a means to trigger user awareness that some APIs may change.
> Many deprecation warnings in wf-core code
> -----------------------------------------
>
> Key: WFCORE-1981
> URL: https://issues.jboss.org/browse/WFCORE-1981
> Project: WildFly Core
> Issue Type: Bug
> Affects Versions: 3.0.0.Alpha12
> Reporter: Rostislav Svoboda
> Assignee: Tomaz Cerar
> Attachments: wf-core-deprecated-log.txt
>
>
> There are many deprecation (281 atm) warnings in wf-core code.
> List of detected deprecations attached.
> updated summary {{mvn -fn clean install -Dmaven.test.skip=true -Dmaven.compiler.showDeprecation=true | tee ~/Downloads/wildfly-core-build-log.txt}}:
> {code}
> grep deprecated wildfly-core-build-log.txt | cut -d] -f3 | sort | uniq -c | sort -n -r
> 92 org.jboss.as.controller.access.Caller in org.jboss.as.controller.access has been deprecated
> 33 org.jboss.msc.service.ServiceListener in org.jboss.msc.service has been deprecated
> 25 SimpleResourceDefinition(org.jboss.as.controller.PathElement,org.jboss.as.controller.descriptions.ResourceDescriptionResolver,org.jboss.as.controller.OperationStepHandler,org.jboss.as.controller.OperationStepHandler,org.jboss.as.controller.registry.OperationEntry.Flag,org.jboss.as.controller.registry.OperationEntry.Flag) in org.jboss.as.controller.SimpleResourceDefinition has been deprecated
> 23 org.jboss.as.controller.CurrentOperationIdHolder in org.jboss.as.controller has been deprecated
> 17 org.xnio.Pool in org.xnio has been deprecated
> 16 org.jboss.as.server.mgmt.domain.ExtensibleHttpManagement in org.jboss.as.server.mgmt.domain has been deprecated
> 16 org.jboss.as.server.ExternalManagementRequestExecutor in org.jboss.as.server has been deprecated
> 12 org.jboss.as.controller.ServiceVerificationHandler in org.jboss.as.controller has been deprecated
> 11 OPTIONAL in org.jboss.msc.service.ServiceBuilder.DependencyType has been deprecated
> 10 org.xnio.ByteBufferSlicePool in org.xnio has been deprecated
> 6 builder(org.jboss.as.controller.PersistentResourceDefinition) in org.jboss.as.controller.PersistentResourceXMLDescription has been deprecated
> 5 SERVICE_NAME in org.wildfly.extension.requestcontroller.RequestController has been deprecated
> 5 org.jboss.as.server.operations.ServerRestartRequiredHandler in org.jboss.as.server.operations has been deprecated
> 5 org.jboss.as.domain.http.server.security.RealmIdentityManager in org.jboss.as.domain.http.server.security has been deprecated
> 4 removePropertyChangeListener(java.beans.PropertyChangeListener) in org.jboss.as.controller.ControlledProcessStateService has been deprecated
> 4 org.jboss.as.controller.extension.ExtensionContextSupplement in org.jboss.as.controller.extension has been deprecated
> 4 addPropertyChangeListener(java.beans.PropertyChangeListener) in org.jboss.as.controller.ControlledProcessStateService has been deprecated
> 4 AbstractControllerService(org.jboss.as.controller.ProcessType,org.jboss.as.controller.RunningModeControl,org.jboss.as.controller.persistence.ConfigurationPersister,org.jboss.as.controller.ControlledProcessState,org.jboss.as.controller.ResourceDefinition,org.jboss.as.controller.OperationStepHandler,org.jboss.as.controller.ExpressionResolver) in org.jboss.as.controller.AbstractControllerService has been deprecated
> 3 transformOperation(org.jboss.as.controller.ModelVersion,org.jboss.dmr.ModelNode,org.jboss.as.controller.transform.TransformerOperationAttachment) in org.jboss.as.subsystem.test.KernelServices has been deprecated
> 3 IMPLEMENTATION_VENDOR_ID in java.util.jar.Attributes.Name has been deprecated
> 3 getCurrentState() in org.jboss.as.controller.ControlledProcessStateService has been deprecated
> 3 executeAndGrabTransformerAttachment(org.jboss.dmr.ModelNode) in org.jboss.as.subsystem.test.KernelServices has been deprecated
> 3 deserialize(javax.management.ObjectName,byte[
> 3 deserialize(java.lang.String,javax.management.ObjectName,byte[
> 3 deserialize(java.lang.String,byte[
> 2 SimpleOperationDefinition(java.lang.String,org.jboss.as.controller.descriptions.ResourceDescriptionResolver,org.jboss.as.controller.descriptions.ResourceDescriptionResolver,org.jboss.as.controller.registry.OperationEntry.EntryType,java.util.EnumSet<org.jboss.as.controller.registry.OperationEntry.Flag>,org.jboss.dmr.ModelType,org.jboss.dmr.ModelType,boolean,org.jboss.as.controller.DeprecationData,org.jboss.as.controller.AttributeDefinition[
> 2 SERVICE_NAME in org.jboss.as.server.ExternalManagementRequestExecutor has been deprecated
> 2 perLoggingDeploymentIgnored(java.lang.String,java.lang.String,java.lang.String) in org.jboss.as.logging.logging.LoggingLogger has been deprecated
> 2 perDeploymentPropertyDeprecated(java.lang.String,java.lang.String) in org.jboss.as.logging.logging.LoggingLogger has been deprecated
> 2 OUTBOUND_SOCKET_BINDING_BASE_SERVICE_NAME in org.jboss.as.network.OutboundSocketBinding has been deprecated
> 2 org.jboss.as.protocol.mgmt.ManagementRequestContext.MultipleResponseAsyncTask in org.jboss.as.protocol.mgmt.ManagementRequestContext has been deprecated
> 2 OperationFailedException(org.jboss.dmr.ModelNode) in org.jboss.as.controller.OperationFailedException has been deprecated
> 2 IMPLEMENTATION_URL in java.util.jar.Attributes.Name has been deprecated
> 2 getDefaultControllerPort() in org.jboss.as.cli.CommandContext has been deprecated
> 2 getDefaultControllerHost() in org.jboss.as.cli.CommandContext has been deprecated
> 2 getCaller() in org.jboss.as.controller.OperationContext has been deprecated
> 2 ExtensionRegistry(org.jboss.as.controller.ProcessType,org.jboss.as.controller.RunningModeControl) in org.jboss.as.controller.extension.ExtensionRegistry has been deprecated
> 2 DOMAIN_EXECUTION_KEY in org.jboss.as.controller.CompositeOperationHandler has been deprecated
> 2 createVault(java.lang.String,java.util.Map<java.lang.String,java.lang.Object>) in org.jboss.as.server.services.security.AbstractVaultReader has been deprecated
> 2 connectController(java.lang.String,int) in org.jboss.as.cli.CommandContext has been deprecated
> 2 builder(org.jboss.as.controller.PersistentResourceDefinition,java.lang.String) in org.jboss.as.controller.PersistentResourceXMLDescription has been deprecated
> 2 AbstractControllerService(org.jboss.as.controller.ProcessType,org.jboss.as.controller.RunningModeControl,org.jboss.as.controller.persistence.ConfigurationPersister,org.jboss.as.controller.ControlledProcessState,org.jboss.as.controller.ResourceDefinition,org.jboss.as.controller.OperationStepHandler,org.jboss.as.controller.ExpressionResolver,org.jboss.as.controller.audit.ManagedAuditLogger,org.jboss.as.controller.access.management.DelegatingConfigurableAuthorizer) in org.jboss.as.controller.AbstractControllerService has been deprecated
> 2 AbstractControllerService(org.jboss.as.controller.ProcessType,org.jboss.as.controller.RunningModeControl,org.jboss.as.controller.persistence.ConfigurationPersister,org.jboss.as.controller.ControlledProcessState,org.jboss.as.controller.descriptions.DescriptionProvider,org.jboss.as.controller.OperationStepHandler,org.jboss.as.controller.ExpressionResolver) in org.jboss.as.controller.AbstractControllerService has been deprecated
> 1 setXmlName(java.lang.String) in org.jboss.as.controller.PropertiesAttributeDefinition.Builder has been deprecated
> 1 setWrapperElement(java.lang.String) in org.jboss.as.controller.PropertiesAttributeDefinition.Builder has been deprecated
> 1 setRuntimeOnly(boolean) in org.jboss.as.controller.registry.ManagementResourceRegistration has been deprecated
> 1 RUNTIME_NAME in org.jboss.as.server.deployment.Attachments has been deprecated
> 1 registerModelTransformers(org.jboss.as.controller.ModelVersionRange,org.jboss.as.controller.transform.ResourceTransformer,org.jboss.as.controller.transform.OperationTransformer,boolean) in org.jboss.as.controller.SubsystemRegistration has been deprecated
> 1 registerModelTransformers(org.jboss.as.controller.ModelVersionRange,org.jboss.as.controller.transform.ResourceTransformer) in org.jboss.as.controller.SubsystemRegistration has been deprecated
> 1 registerModelTransformers(org.jboss.as.controller.ModelVersionRange,org.jboss.as.controller.transform.CombinedTransformer) in org.jboss.as.controller.SubsystemRegistration has been deprecated
> 1 PROCESS_STATE in org.jboss.as.server.controller.descriptions.ServerDescriptionConstants has been deprecated
> 1 org.wildfly.core.embedded.ServerStartException in org.wildfly.core.embedded has been deprecated
> 1 ManagedDMRContentTypeResource(org.jboss.as.controller.PathElement,java.lang.String,byte[
> 1 JBOSS_BINDING_NAME in org.jboss.as.network.SocketBinding has been deprecated
> 1 isRegisterTransformers() in org.jboss.as.controller.ExtensionContext has been deprecated
> 1 installConnectorServicesForNetworkInterfaceBinding(org.jboss.msc.service.ServiceTarget,org.jboss.msc.service.ServiceName,java.lang.String,org.jboss.msc.service.ServiceName,int,org.xnio.OptionMap,org.jboss.msc.service.ServiceName,org.jboss.msc.service.ServiceName,org.jboss.msc.service.ServiceName) in org.jboss.as.remoting.RemotingServices has been deprecated
> 1 HttpOpenListener(org.xnio.Pool<java.nio.ByteBuffer>) in io.undertow.server.protocol.http.HttpOpenListener has been deprecated
> 1 getDeploymentSubsystemModel(java.lang.String) in org.jboss.as.server.deployment.DeploymentUnit has been deprecated
> 1 executeReadOnlyOperation(org.jboss.dmr.ModelNode,org.jboss.as.controller.registry.Resource,org.jboss.as.controller.ModelController.OperationTransactionControl,org.jboss.as.controller.OperationStepHandler) in org.jboss.as.controller.AbstractControllerService has been deprecated
> 1 executeReadOnlyOperation(org.jboss.dmr.ModelNode,org.jboss.as.controller.ModelController.OperationTransactionControl,org.jboss.as.controller.OperationStepHandler) in org.jboss.as.controller.AbstractControllerService has been deprecated
> 1 enableTransformerAttachmentGrabber() in org.jboss.as.subsystem.test.KernelServicesBuilder has been deprecated
> 1 currentAccessAuditContext() in org.jboss.as.controller.AccessAuditContext has been deprecated
> 1 createDeploymentSubModel(java.lang.String,org.jboss.as.controller.PathElement) in org.jboss.as.server.deployment.DeploymentUnit has been deprecated
> 1 createDeploymentSubModel(java.lang.String,org.jboss.as.controller.PathAddress,org.jboss.as.controller.registry.Resource) in org.jboss.as.server.deployment.DeploymentUnit has been deprecated
> 1 createDeploymentSubModel(java.lang.String,org.jboss.as.controller.PathAddress) in org.jboss.as.server.deployment.DeploymentUnit has been deprecated
> 1 buildAndRegister(org.jboss.as.controller.SubsystemRegistration,org.jboss.as.controller.ModelVersion[
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-7578) Inconsistencies in using fileType/path+relative-to in Elytron XSD/DMR
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7578?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on WFLY-7578:
----------------------------------------
This level of consistence is not something that should be expected. The management model and schema are two different representations of the same configuration.
> Inconsistencies in using fileType/path+relative-to in Elytron XSD/DMR
> ---------------------------------------------------------------------
>
> Key: WFLY-7578
> URL: https://issues.jboss.org/browse/WFLY-7578
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Kotek
> Assignee: Darran Lofthouse
> Labels: user_experience
>
> *Issue description:*
> In _wildfly-elytron_1_0.xsd_, a file type is represented inconsistently. There are {{basicFileType}} and {{fileType}} complex types used, but there are also {{path}} and {{relative-to}} attributes used ({{providerLoadersType}}, {{kerberosSecurityFactory}}).
> In DMR, file is represented as object (e.g. {{properties-realm}}) or as attributes (e.g. {{filesystem-realm}}, {{key-store}}).
> *Suggestions for improvement:*
> The file representation should be consistent in XSD/DMR.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-7578) Inconsistencies in using fileType/path+relative-to in Elytron XSD/DMR
by Ondrej Kotek (JIRA)
[ https://issues.jboss.org/browse/WFLY-7578?page=com.atlassian.jira.plugin.... ]
Ondrej Kotek moved JBEAP-7254 to WFLY-7578:
-------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-7578 (was: JBEAP-7254)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Security
(was: Security)
(was: User Experience)
Affects Version/s: 11.0.0.Alpha1
(was: 7.1.0.DR8)
> Inconsistencies in using fileType/path+relative-to in Elytron XSD/DMR
> ---------------------------------------------------------------------
>
> Key: WFLY-7578
> URL: https://issues.jboss.org/browse/WFLY-7578
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Kotek
> Assignee: Darran Lofthouse
> Labels: user_experience
>
> *Issue description:*
> In _wildfly-elytron_1_0.xsd_, a file type is represented inconsistently. There are {{basicFileType}} and {{fileType}} complex types used, but there are also {{path}} and {{relative-to}} attributes used ({{providerLoadersType}}, {{kerberosSecurityFactory}}).
> In DMR, file is represented as object (e.g. {{properties-realm}}) or as attributes (e.g. {{filesystem-realm}}, {{key-store}}).
> *Suggestions for improvement:*
> The file representation should be consistent in XSD/DMR.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-6747) messaging subsystem bridge fails on differents Ip orders
by Lorenzo Pirazzini (JIRA)
[ https://issues.jboss.org/browse/WFLY-6747?page=com.atlassian.jira.plugin.... ]
Lorenzo Pirazzini commented on WFLY-6747:
-----------------------------------------
Hello, I'm still not aware why the IPs order is important in the HornetQ configuration, and this leads me to another issue: if I have a wildfly domain and the domain controller shuts down, when I start it after the failure the hornetQ bridge is not created again. Why?
> messaging subsystem bridge fails on differents Ip orders
> --------------------------------------------------------
>
> Key: WFLY-6747
> URL: https://issues.jboss.org/browse/WFLY-6747
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 8.2.0.Final
> Environment: Wildfly 8.2.0.Final domain mode. 2 Hosts each one with one server, one contains also the domain controller. Verified on Windows and on Linux (AWS machines).
> Reporter: Lorenzo Pirazzini
> Assignee: Jeff Mesnil
>
> While trying to setup a clustered environment with Wildfly 8.2.0.Final I needed a shared topic between servers (I have two Linux machines on AWS).
> Everything works fine (domain creation, datasources/persistence unit, infinispan shared caches and Wildfly Console) except for HornetQ messaging subsystem.
> I can't use discovery because I don't have a multicast address, so I defined a *domain.xml* like this:
> <subsystem xmlns="urn:jboss:domain:messaging:2.0">
> <hornetq-server>
> <cluster-password>myPassword</cluster-password>
> <backup>false</backup>
> <shared-store>false</shared-store>
> <journal-file-size>102400</journal-file-size>
> <connectors>
> <http-connector name="http-connector" socket-binding="http">
> <param key="http-upgrade-endpoint" value="http-acceptor"/>
> </http-connector>
> <http-connector name="http-connector-throughput" socket-binding="http">
> <param key="http-upgrade-endpoint" value="http-acceptor-throughput"/>
> <param key="batch-delay" value="50"/>
> </http-connector>
> <http-connector name="cnode1" socket-binding="node1">
> <param key="http-upgrade-endpoint" value="http-acceptor"/>
> </http-connector>
> <http-connector name="cnode2" socket-binding="node2">
> <param key="http-upgrade-endpoint" value="http-acceptor"/>
> </http-connector>
> <in-vm-connector name="in-vm" server-id="0"/>
> </connectors>
> <acceptors>
> <http-acceptor http-listener="default" name="http-acceptor"/>
> <http-acceptor http-listener="default" name="http-acceptor-throughput">
> <param key="batch-delay" value="50"/>
> <param key="direct-deliver" value="false"/>
> </http-acceptor>
> <in-vm-acceptor name="in-vm" server-id="0"/>
> </acceptors>
> <cluster-connections>
> <cluster-connection name="my-cluster">
> <address>jms</address>
> <connector-ref>http-connector</connector-ref>
> <static-connectors>
> <connector-ref>
> cnode1
> </connector-ref>
> <connector-ref>
> cnode2
> </connector-ref>
> </static-connectors>
> </cluster-connection>
> </cluster-connections>
> <security-settings>
> <security-setting match="#">
> <permission type="send" roles="guest"/>
> <permission type="consume" roles="guest"/>
> <permission type="createNonDurableQueue" roles="guest"/>
> <permission type="deleteNonDurableQueue" roles="guest"/>
> </security-setting>
> </security-settings>
> <address-settings>
> <address-setting match="#">
> <dead-letter-address>jms.queue.DLQ</dead-letter-address>
> <expiry-address>jms.queue.ExpiryQueue</expiry-address>
> <max-size-bytes>10485760</max-size-bytes>
> <page-size-bytes>2097152</page-size-bytes>
> <message-counter-history-day-limit>10</message-counter-history-day-limit>
> <redistribution-delay>1000</redistribution-delay>
> </address-setting>
> </address-settings>
> <jms-connection-factories>
> <connection-factory name="InVmConnectionFactory">
> <connectors>
> <connector-ref connector-name="in-vm"/>
> </connectors>
> <entries>
> <entry name="java:/ConnectionFactory"/>
> </entries>
> </connection-factory>
> <connection-factory name="RemoteConnectionFactory">
> <connectors>
> <connector-ref connector-name="http-connector"/>
> </connectors>
> <entries>
> <entry name="java:jboss/exported/jms/RemoteConnectionFactory"/>
> </entries>
> <ha>true</ha>
> <block-on-acknowledge>true</block-on-acknowledge>
> <reconnect-attempts>-1</reconnect-attempts>
> </connection-factory>
> <pooled-connection-factory name="hornetq-ra">
> <transaction mode="xa"/>
> <connectors>
> <connector-ref connector-name="in-vm"/>
> </connectors>
> <entries>
> <entry name="java:/JmsXA"/>
> <entry name="java:jboss/DefaultJMSConnectionFactory"/>
> </entries>
> </pooled-connection-factory>
> </jms-connection-factories>
> <jms-destinations>
> ...
> <jms-topic name="MyTopic">
> <entry name="java:/jms/topic/MyTopic"/>
> </jms-topic>
> ...
> </jms-destinations>
> </hornetq-server>
> </subsystem>
> ...
> <socket-binding-group name="full-ha-sockets" default-interface="public">
> <socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>
> <socket-binding name="http" port="${jboss.http.port:8080}"/>
> <socket-binding name="https" port="${jboss.https.port:8443}"/>
> <socket-binding name="jacorb" interface="unsecure" port="3528"/>
> <socket-binding name="jacorb-ssl" interface="unsecure" port="3529"/>
> <socket-binding name="jgroups-mping" port="0" multicast-address="${jboss.default.multicast.address:230.0.0.4}" multicast-port="45700"/>
> <socket-binding name="jgroups-tcp" port="7600"/>
> <socket-binding name="jgroups-tcp-fd" port="57600"/>
> <socket-binding name="jgroups-udp" port="55200" multicast-address="${jboss.default.multicast.address:230.0.0.4}" multicast-port="45688"/>
> <socket-binding name="jgroups-udp-fd" port="54200"/>
> <socket-binding name="messaging-group" port="0" multicast-address="${jboss.messaging.group.address:231.7.7.7}" multicast-port="${jboss.messaging.group.port:9876}"/>
> <socket-binding name="txn-recovery-environment" port="4712"/>
> <socket-binding name="txn-status-manager" port="4713"/>
> <outbound-socket-binding name="mail-smtp">
> <remote-destination host="localhost" port="25"/>
> </outbound-socket-binding>
> <outbound-socket-binding name="node1">
> <remote-destination host="IP-A" port="8080"/>
> </outbound-socket-binding>
> <outbound-socket-binding name="node2">
> <remote-destination host="IP-B" port="8080"/>
> </outbound-socket-binding>
> </socket-binding-group>
> </socket-binding-groups>
> where IP-A is the Ip of the host with domain controller and a server, and IP-B is the address of the host with only a server instance.
> If I invert those two IPs HornetQ doesn't create the bridge! The topic isn't shared, every message is processed only by the topic owned by the current server.
> Why the order of sucjh addresses determines the correct behaviour of the messaging subsystem? I haven't found anything useful on the documentation, am I missing something??
> This is the line which is written only in the order proposed which starts the HornetQ shared topics:
> 2016-06-20 12:18:17,943 INFO [org.hornetq.core.server] (Thread-29 (HornetQ-server-HornetQServerImpl::serverUUID=ead3e226-2c7c-11e6-81c9-1fb90d688ead-2097612799)) HQ221027: Bridge ClusterConnectionBridge@4862c348 [name=sf.my-cluster.25728e77-2c02-11e6-8d49-3995f9ecf159, queue=QueueImpl[name=sf.my-cluster.25728e77-2c02-11e6-8d49-3995f9ecf159, postOffice=PostOfficeImpl [server=HornetQServerImpl::serverUUID=ead3e226-2c7c-11e6-81c9-1fb90d688ead]]@4ceda5a4 targetConnector=ServerLocatorImpl (identity=(Cluster-connection-bridge::ClusterConnectionBridge@4862c348 [name=sf.my-cluster.25728e77-2c02-11e6-8d49-3995f9ecf159, queue=QueueImpl[name=sf.my-cluster.25728e77-2c02-11e6-8d49-3995f9ecf159, postOffice=PostOfficeImpl [server=HornetQServerImpl::serverUUID=ead3e226-2c7c-11e6-81c9-1fb90d688ead]]@4ceda5a4 targetConnector=ServerLocatorImpl [initialConnectors=[TransportConfiguration(name=http-connector, factory=org-hornetq-core-remoting-impl-netty-NettyConnectorFactory) ?port=8080&http-upgrade-endpoint=http-acceptor&host=IP_B&http-upgrade-enabled=true], discoveryGroupConfiguration=null]]::ClusterConnectionImpl@1383156397[nodeUUID=ead3e226-2c7c-11e6-81c9-1fb90d688ead, connector=TransportConfiguration(name=http-connector, factory=org-hornetq-core-remoting-impl-netty-NettyConnectorFactory) ?port=8080&host=IP-A&http-upgrade-endpoint=http-acceptor&http-upgrade-enabled=true, address=jms, server=HornetQServerImpl::serverUUID=ead3e226-2c7c-11e6-81c9-1fb90d688ead])) [initialConnectors=[TransportConfiguration(name=http-connector, factory=org-hornetq-core-remoting-impl-netty-NettyConnectorFactory) ?port=8080&http-upgrade-endpoint=http-acceptor&host=IP-B&http-upgrade-enabled=true], discoveryGroupConfiguration=null]] is connected
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-6599) JDBC_PING can't use a JNDI database connection because it is closed on shutdown
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6599?page=com.atlassian.jira.plugin.... ]
Radoslav Husar resolved WFLY-6599.
----------------------------------
Resolution: Done
> JDBC_PING can't use a JNDI database connection because it is closed on shutdown
> -------------------------------------------------------------------------------
>
> Key: WFLY-6599
> URL: https://issues.jboss.org/browse/WFLY-6599
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final
> Reporter: Matthew Casperson
> Assignee: Radoslav Husar
> Fix For: 11.0.0.Alpha1
>
>
> If you configure the JDBC_PING protocol in JGroups to use a datasource provided by WildFly via the *datasource_jndi_name* setting, you'll get the following exception when WildFly is shutdown:
> {code}
> [Server:main-server] 2016-05-10 11:05:45+1000 ERROR [[org.jgroups.protocols.JDBC_PING]] [[MSC service thread 1-4]] Could not open connection to database: java.sql.SQLException: javax.resource.ResourceException: IJ000470: You are trying to use a connection factory that has been shut down: java:/comp/env/jdbc/jgroups
> [Server:main-server] at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:146)
> [Server:main-server] at org.jboss.as.connector.subsystems.datasources.WildFlyDataSource.getConnection(WildFlyDataSource.java:66)
> [Server:main-server] at org.jgroups.protocols.JDBC_PING.getConnection(JDBC_PING.java:348)
> [Server:main-server] at org.jgroups.protocols.JDBC_PING.delete(JDBC_PING.java:379)
> [Server:main-server] at org.jgroups.protocols.JDBC_PING.deleteSelf(JDBC_PING.java:395)
> [Server:main-server] at org.jgroups.protocols.JDBC_PING.stop(JDBC_PING.java:144)
> [Server:main-server] at org.jgroups.stack.ProtocolStack.stopStack(ProtocolStack.java:1015)
> [Server:main-server] at org.jgroups.JChannel.stopStack(JChannel.java:1002)
> [Server:main-server] at org.jgroups.JChannel.disconnect(JChannel.java:373)
> [Server:main-server] at org.wildfly.clustering.jgroups.spi.service.ChannelConnectorBuilder.stop(ChannelConnectorBuilder.java:103)
> [Server:main-server] at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2056)
> [Server:main-server] at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2017)
> [Server:main-server] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Server:main-server] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Server:main-server] at java.lang.Thread.run(Thread.java:745)
> [Server:main-server] Caused by: javax.resource.ResourceException: IJ000470: You are trying to use a connection factory that has been shut down: java:/comp/env/jdbc/jgroups
> [Server:main-server] at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:735)
> [Server:main-server] at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:138)
> [Server:main-server] ... 14 more
> {code}
> The solution is to configure the database connection directly, but then it seems that you loose the ability to use features like database connection validation, reconnection and the other settings provided by a WildFly datasource the improve the reliability of a database connection.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-6599) JDBC_PING can't use a JNDI database connection because it is closed on shutdown
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6599?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-6599:
---------------------------------
Comment: was deleted
(was: A comment with security level 'Red Hat Employee' was removed.)
> JDBC_PING can't use a JNDI database connection because it is closed on shutdown
> -------------------------------------------------------------------------------
>
> Key: WFLY-6599
> URL: https://issues.jboss.org/browse/WFLY-6599
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final
> Reporter: Matthew Casperson
> Assignee: Radoslav Husar
> Fix For: 11.0.0.Alpha1
>
>
> If you configure the JDBC_PING protocol in JGroups to use a datasource provided by WildFly via the *datasource_jndi_name* setting, you'll get the following exception when WildFly is shutdown:
> {code}
> [Server:main-server] 2016-05-10 11:05:45+1000 ERROR [[org.jgroups.protocols.JDBC_PING]] [[MSC service thread 1-4]] Could not open connection to database: java.sql.SQLException: javax.resource.ResourceException: IJ000470: You are trying to use a connection factory that has been shut down: java:/comp/env/jdbc/jgroups
> [Server:main-server] at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:146)
> [Server:main-server] at org.jboss.as.connector.subsystems.datasources.WildFlyDataSource.getConnection(WildFlyDataSource.java:66)
> [Server:main-server] at org.jgroups.protocols.JDBC_PING.getConnection(JDBC_PING.java:348)
> [Server:main-server] at org.jgroups.protocols.JDBC_PING.delete(JDBC_PING.java:379)
> [Server:main-server] at org.jgroups.protocols.JDBC_PING.deleteSelf(JDBC_PING.java:395)
> [Server:main-server] at org.jgroups.protocols.JDBC_PING.stop(JDBC_PING.java:144)
> [Server:main-server] at org.jgroups.stack.ProtocolStack.stopStack(ProtocolStack.java:1015)
> [Server:main-server] at org.jgroups.JChannel.stopStack(JChannel.java:1002)
> [Server:main-server] at org.jgroups.JChannel.disconnect(JChannel.java:373)
> [Server:main-server] at org.wildfly.clustering.jgroups.spi.service.ChannelConnectorBuilder.stop(ChannelConnectorBuilder.java:103)
> [Server:main-server] at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2056)
> [Server:main-server] at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2017)
> [Server:main-server] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Server:main-server] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Server:main-server] at java.lang.Thread.run(Thread.java:745)
> [Server:main-server] Caused by: javax.resource.ResourceException: IJ000470: You are trying to use a connection factory that has been shut down: java:/comp/env/jdbc/jgroups
> [Server:main-server] at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:735)
> [Server:main-server] at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:138)
> [Server:main-server] ... 14 more
> {code}
> The solution is to configure the database connection directly, but then it seems that you loose the ability to use features like database connection validation, reconnection and the other settings provided by a WildFly datasource the improve the reliability of a database connection.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (ELY-752) Coverity static analysis: Dereference null return value in SerializedPermissionCollection (Elytron)
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/ELY-752?page=com.atlassian.jira.plugin.sy... ]
David Lloyd resolved ELY-752.
-----------------------------
Resolution: Rejected
What Coverity cannot see is that SerializedPermissionCollection is only ever generated for classes which have a newPermissionCollection method which has a non-null return value. Thus I think this is actually "safe" and there is no case which can produce an NPE (other than a corrupted stream, which can produce all manner of other problems as well).
> Coverity static analysis: Dereference null return value in SerializedPermissionCollection (Elytron)
> ---------------------------------------------------------------------------------------------------
>
> Key: ELY-752
> URL: https://issues.jboss.org/browse/ELY-752
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Josef Cacek
> Assignee: Darran Lofthouse
> Labels: static_analysis
>
> Coverity static-analysis scan found possible use of null object comming from {{SerializedPermissionCollection.readResolve()}} method.
> https://scan7.coverity.com/reports.htm#v16159/p11778/fileInstanceId=57600...
> The {{newPermissionCollection()}} call may return null in the code:
> {code}
> final PermissionCollection collection = s.newPermissionCollection();
> {code}
> It's than used without a null-check in the method:
> {code}
> for (Permission permission : p) {
> collection.add(permission);
> }
> if (r) collection.setReadOnly();
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (DROOLS-1345) Drop support for JSR94 integration?
by Petr Široký (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1345?page=com.atlassian.jira.plugi... ]
Petr Široký commented on DROOLS-1345:
-------------------------------------
This may be harder to remove that expected. It seems some people are still using it. That's fine, we just need a sources for the jsr94 jar. [~mfusco] or [~mark.proctor] do you know if those sources are available somewhere? (I was not able to find anything googling for a while).
> Drop support for JSR94 integration?
> -----------------------------------
>
> Key: DROOLS-1345
> URL: https://issues.jboss.org/browse/DROOLS-1345
> Project: Drools
> Issue Type: Task
> Components: core engine
> Affects Versions: 7.0.0.Beta2
> Reporter: Petr Široký
> Assignee: Petr Široký
>
> Drools JSR94 integration seems to be unused and unmaintained. We should at least consider removing it for 7.x
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months