[JBoss JIRA] (WFCORE-1808) Operation to list dependencies/dependents for a deployment
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1808?page=com.atlassian.jira.plugi... ]
Brian Stansberry moved WFLY-7136 to WFCORE-1808:
------------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-1808 (was: WFLY-7136)
Affects Version/s: (was: 10.1.0.Final)
> Operation to list dependencies/dependents for a deployment
> ----------------------------------------------------------
>
> Key: WFCORE-1808
> URL: https://issues.jboss.org/browse/WFCORE-1808
> Project: WildFly Core
> Issue Type: Feature Request
> Reporter: Guillermo González de Agüero
> Assignee: Jason Greene
>
> If a deployment "A" has a dependency on deployment "B", and "B" is undeployed, "A" automatically changes its status to FAILED.
> It's currently not possible to list what dependencies and dependents a deployment has. With two new operations (e.g. dependency-list and dependent-list) on the deployment resource, HAL could provide a confirmation dialog warning the user of side effects when undeploying.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFCORE-1808) Operation to list dependencies/dependents for a deployment
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1808?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-1808:
----------------------------------------
Component/s: Domain Management
Assignee: (was: Jason Greene)
> Operation to list dependencies/dependents for a deployment
> ----------------------------------------------------------
>
> Key: WFCORE-1808
> URL: https://issues.jboss.org/browse/WFCORE-1808
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Guillermo González de Agüero
>
> If a deployment "A" has a dependency on deployment "B", and "B" is undeployed, "A" automatically changes its status to FAILED.
> It's currently not possible to list what dependencies and dependents a deployment has. With two new operations (e.g. dependency-list and dependent-list) on the deployment resource, HAL could provide a confirmation dialog warning the user of side effects when undeploying.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7139) IllegalStateException: WFLYEE0043: Component is stopped
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-7139?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz moved JBEAP-6064 to WFLY-7139:
--------------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-7139 (was: JBEAP-6064)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Clustering
(was: Clustering)
Affects Version/s: 11.0.0.Alpha1
(was: 7.1.0.DR3)
> IllegalStateException: WFLYEE0043: Component is stopped
> -------------------------------------------------------
>
> Key: WFLY-7139
> URL: https://issues.jboss.org/browse/WFLY-7139
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 11.0.0.Alpha1
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Labels: clean_undeploy
>
> Occured on client during remote EJB undeploy failover tests. Scenarios:
> eap-7x-failover-ejb-ejbremote-undeploy-dist-async,
> eap-7x-failover-ejb-ejbremote-undeploy-repl-async,
> eap-7x-failover-ejb-ejbremote-undeploy-repl-sync.
> Happened after "Failing node 0 (perf18)" at 2016/08/18 11:59:51:537 and stopped occuring at 2016/08/18 12:06:04:494 just before "Node 3 (perf21) is down".
> Stacktrace from client:
> {code}
> 2016/08/18 11:59:52:694 EDT [ERROR][Runner - 1092] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error getting response. <java.lang.IllegalStateException: WFLYEE0043: Component is stopped>
> java.lang.IllegalStateException: WFLYEE0043: Component is stopped
> at org.jboss.as.ee.component.BasicComponent.waitForComponentStart(BasicComponent.java:110)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:194)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:328)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:67)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:201)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:263)
> at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213)
> at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76)
> at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:159)
> at org.jboss.remoting3.remote.RemoteConnectionChannel$4.run(RemoteConnectionChannel.java:383)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:731)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at ...asynchronous invocation...(Unknown Source)
> at org.jboss.ejb.client.remoting.InvocationExceptionResponseHandler$MethodInvocationExceptionResultProducer.getResult(InvocationExceptionResponseHandler.java:96)
> at org.jboss.ejb.client.EJBClientInvocationContext$1.run(EJBClientInvocationContext.java:282)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:279)
> at org.jboss.ejb.client.EJBObjectInterceptor.handleInvocationResult(EJBObjectInterceptor.java:64)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at org.jboss.ejb.client.EJBHomeInterceptor.handleInvocationResult(EJBHomeInterceptor.java:88)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at org.jboss.ejb.client.TransactionInterceptor.handleInvocationResult(TransactionInterceptor.java:46)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at org.jboss.ejb.client.ReceiverInterceptor.handleInvocationResult(ReceiverInterceptor.java:142)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:265)
> at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:453)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:204)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:183)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:146)
> at com.sun.proxy.$Proxy2.getSerialAndIncrement(Unknown Source)
> at org.jboss.smartfrog.clustering.ejb3.StatefulSBProcessorFactoryImpl$EJB3RequestProcessor.processRequest(StatefulSBProcessorFactoryImpl.java:84)
> at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:52)
> at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:103)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> Link to client logs:
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-Clust...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (ELY-627) Elytron introduces SSL/TLS protocol constraints
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-627?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina edited comment on ELY-627 at 9/19/16 9:05 AM:
---------------------------------------------------------
*To discuss:* Should be Protocol enum removed and Strings used instead?
(Alternative: only allow standard names ("TLSv1.2" - with dots) and add Oracle protocol names)
was (Author: honza889):
*To discuss:* Should be Protocol enum removed and Strings used instead?
(Alternative: only allow standard names ("TLSv1.2") and add Oracle protocol names)
> Elytron introduces SSL/TLS protocol constraints
> -----------------------------------------------
>
> Key: ELY-627
> URL: https://issues.jboss.org/browse/ELY-627
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SSL
> Affects Versions: 1.1.0.Beta8
> Reporter: Martin Choma
> Assignee: Jan Kalina
> Priority: Critical
>
> {noformat}
> "protocols" => {
> "type" => LIST,
> "description" => "The enabled protocols.",
> "expressions-allowed" => true,
> "nillable" => false,
> "allowed" => [
> "SSLv2",
> "SSLv3",
> "TLSv1",
> "TLSv1_1",
> "TLSv1_2",
> "TLSv1_3"
> ],
> "value-type" => STRING,
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "resource-services"
> },
> {noformat}
> Why elytron on this place is going to validate user input and map standard java values [1] into proprietary values?
> Whereas on other similar places (KeyManager algorithm, TrustManager algorithm, Keystore types) it leaves up to user to set proper value.
> IMO, with such mapping another place, where bugs can raise was introduced. EAP will be here always one step back compared to java.
> Note, IBM java already today defines little bit different protocols set [2]
> I wonder, where is that mapping "TLSv1_2 -> TLSv1.2" acually performed? I couldn't find that place.
> [1] https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardN...
> [2] http://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.secu...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7134) Upgrade to Wildfly 10.0.0.Final: Messaging System issue
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-7134?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar closed WFLY-7134.
-----------------------------
Assignee: (was: Jeff Mesnil)
Resolution: Rejected
Please use forums https://developer.jboss.org/en/wildfly for user help with migration.
Jira is bug tracker where we track bugs that are confirmed as such not just a user usage problem.
> Upgrade to Wildfly 10.0.0.Final: Messaging System issue
> -------------------------------------------------------
>
> Key: WFLY-7134
> URL: https://issues.jboss.org/browse/WFLY-7134
> Project: WildFly
> Issue Type: Component Upgrade
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Preeta Kuruvilla
> Priority: Blocker
> Attachments: standalone-full-WL-10.0.Final.xml, standalone-full-WL-8.2.xml
>
>
> Widlffly 8.2 was based on HornetQ JMS message broker while Wildfly 10 uses ActiveMQ JMS message broker.
> The HornetQ code base was donated to the Apache ActiveMQ community late last year and now resides as a sub project under the ActiveMQ umbrella named 'Artemis’. http://activemq.apache.org/artemis.
> http://hornetq.blogspot.in/2015/06/hornetq-apache-donation-and-apache.html
> The issue we are facing is after we upgraded our application to wildfly 10.0.0.Final from Wildfly 8.2 the messages are not consistently getting into the queue. Below is how we configured the messaging subsystem in standalone-full.xml:-
> Let me know if this is good. Also I have attached the entire standalone-full.xml with this case.
> <subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0">
> <server name="default">
> <security enabled="false"/>
> <statistics enabled="true"/>
> <security-setting name="#">
> <role name="guest" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/>
> <role name="jmsrole" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/>
> </security-setting>
> <address-setting name="#" redistribution-delay="1000" message-counter-history-day-limit="10" page-size-bytes="2097152" max-size-bytes="10485760" expiry-address="jms.queue.ExpiryQueue" dead-letter-address="jms.queue.DLQ"/>
> <http-connector name="http-connector" endpoint="http-acceptor" socket-binding="remote-http"/>
> <http-connector name="http-connector-throughput" endpoint="http-acceptor-throughput" socket-binding="http"/>
> <in-vm-connector name="in-vm" server-id="0"/>
> <http-acceptor name="http-acceptor" http-listener="default"/>
> <http-acceptor name="http-acceptor-throughput" http-listener="default">
> <param name="batch-delay" value="50"/>
> <param name="direct-deliver" value="false"/>
> </http-acceptor>
> <in-vm-acceptor name="in-vm" server-id="0"/>
> <jms-queue name="testQueue" entries="java:/queue/test java:jboss/exported/jms/queue/test"/>
> <jms-queue name="ISEEOutboundQueue" entries="java:/ISEEOutboundQueue java:jboss/exported/jms/queue/ISEEOutboundQueue"/>
> <jms-queue name="ISEEInboundQueue" entries="java:/ISEEInboundQueue java:jboss/exported/jms/queue/ISEEInboundQueue"/>
> <jms-queue name="BEEEAuthorizationsQueue" entries="java:/BEEEAuthorizationsQueue java:jboss/exported/jms/queue/BEEEAuthorizationsQueue"/>
> <jms-queue name="BEEERequisitionsQueue" entries="java:/BEEERequisitionsQueue java:jboss/exported/jms/queue/BEEERequisitionsQueue"/>
> <jms-queue name="BEEEInboundQueue" entries="java:/BEEEInboundQueue java:jboss/exported/jms/queue/BEEEInboundQueue"/>
> <jms-topic name="testTopic" entries="java:/topic/test java:jboss/exported/jms/topic/test"/>
> <connection-factory name="InVmConnectionFactory" entries="java:/ConnectionFactory" connectors="in-vm"/>
> <connection-factory name="RemoteConnectionFactory" entries="java:/RemoteConnectionFactory java:jboss/exported/jms/RemoteConnectionFactory" connectors="http-connector"/>
> <pooled-connection-factory name="activemq-ra" transaction="xa" entries="/JmsXA jboss/DefaultJMSConnectionFactory" connectors="in-vm"/>
> </server>
> </subsystem>
> InitialContext is created with parameters - jmsuser, password, and
> BEEERequisitions.JndiProviderUrl=http-remoting://<ip-address>:<port>
> BEEERequisitions.JndiFactory=org.jboss.naming.remote.client.InitialContextFactory
> Issue we face is that after we upgraded to wildfly 10, the messages are not getting in the queues. This is not consistent as once in a while messages are getting processed.
> I have attached the below standalone-full.xml for your reference :-
> 1. standalone-full-WL-8.2.xml is for Wildfly 8.2 which is working fine.
> 2. standalone-full-WL-10.0.Final.xml is for Wildfly 10.0.Final which has this JMS issue.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-7137) Attribute "required" on key-store makes no difference of behaviour
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7137?page=com.atlassian.jira.plugin.... ]
Jan Kalina reassigned WFLY-7137:
--------------------------------
Assignee: Jan Kalina (was: Darran Lofthouse)
> Attribute "required" on key-store makes no difference of behaviour
> ------------------------------------------------------------------
>
> Key: WFLY-7137
> URL: https://issues.jboss.org/browse/WFLY-7137
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Jan Kalina
> Priority: Critical
>
> There is attribute {{required}} which can be set on key-store, that should disable check "does keystore file exists?"
> {code}
> "required" => {
> "type" => BOOLEAN,
> "description" => "Is the file required to exist at the time the KeyStore service starts?",
> "attribute-group" => "file",
> "expressions-allowed" => true,
> "nillable" => true,
> "default" => false,
> "requires" => ["path"],
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "resource-services"
> },
> {code}
> However, when I try to use it, there is no difference if {{required}} attribute is set to true or false.
> {code}
> [standalone@localhost:9990 /] /subsystem=elytron/key-store=server:add(type="jks", path="/path/non-existing", required=false)
> {
> "outcome" => "failed",
> "failure-description" => {
> "WFLYCTL0080: Failed services" => {"org.wildfly.security.key-store.server" => "org.jboss.msc.service.StartException in service org.wildfly.security.key-store.server: WFLYELY00004: Unable to start the service.
> Caused by: java.io.FileNotFoundException: /path/non-existing (No such file or directory)"},
> "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.key-store.server"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
> },
> "rolled-back" => true
> }
> [standalone@localhost:9990 /] /subsystem=elytron/key-store=server:add(type="jks", path="/path/non-existing", required=true)
> {
> "outcome" => "failed",
> "failure-description" => {
> "WFLYCTL0080: Failed services" => {"org.wildfly.security.key-store.server" => "org.jboss.msc.service.StartException in service org.wildfly.security.key-store.server: WFLYELY00004: Unable to start the service.
> Caused by: java.io.FileNotFoundException: /path/non-existing (No such file or directory)"},
> "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.key-store.server"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
> },
> "rolled-back" => true
> }
> {code}
> I have already seen people generating keystores in their app, so I think this option would be useful for them.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (DROOLS-1298) MemoryUtil should not fail on Google App Engine with NoClassDefFoundError
by Mario Fusco (JIRA)
Mario Fusco created DROOLS-1298:
-----------------------------------
Summary: MemoryUtil should not fail on Google App Engine with NoClassDefFoundError
Key: DROOLS-1298
URL: https://issues.jboss.org/browse/DROOLS-1298
Project: Drools
Issue Type: Enhancement
Components: core engine
Affects Versions: 6.4.0.Final, 6.5.0.CR1, 7.0.0.Beta1
Reporter: Geoffrey De Smet
Assignee: Mario Fusco
Fix For: 7.0.0.Beta2
MemoryUtil throws this exception on Google App Engine:
{code}
java.lang.NoClassDefFoundError: Could not initialize class
com.google.apphosting.runtime.security.shared.stub.java.lang.management.ManagementFactory
at org.drools.core.util.MemoryUtil.<clinit>(MemoryUtil.java:33)
{code}
because the PermGen check goes the wrong way on GAE.
In the MemoryUtil code on line 33, we need something like:
{code}
if (... || isGAE()) {
...
}
public boolean isGAE() {
String p = System.getProperty("com.google.appengine.runtime.environment");
return p != null && !p.equals("");
}
{code}
On GAE, p is "Development". => act same like isAndroid()
On GCE (= plain old OpenJDK), p is null. => act normally
On plain Fedora with OpenJDK 8, p is null. => act normally
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months