[JBoss JIRA] (WFLY-6642) Automatic creation of transport config in IOR settings
by Tomasz Adamski (JIRA)
[ https://issues.jboss.org/browse/WFLY-6642?page=com.atlassian.jira.plugin.... ]
Tomasz Adamski updated WFLY-6642:
---------------------------------
Description: I propose that the transport config parameters configured in ior settings, which later are present in the description of all corba object IORs created in the server, are created automatically. I don't like the idea of manual configuration as it provides invalid description of actual transport parameters in most circumstances. We are providing either standard socket transport or (if configured) SSL transport. Currently user is responsible for providing transport description. So if for example user configures SSL transport but doesn't change transport config then transport description in ior settings is invalid. What is more transport config is currently used to configure required SSL connection - that is if user wants to configure SSL connection he has to specify at least one SSL related transport field as required. This is imo inelegant and not much user friendly. I propose the following change: transport config is created automatically. If user configures SSL then all transport fields provided by SSL (f.e. confidentiality) will be set as supported. To configure required ssl connections server-requires-ssl field in security tag is introduced. If this field is set to true, then all SSL transport fields will be set as required. (was: I propose that the transport config parameters configured in ior settings, which later are present in the description of all corba object IORs created in the server, are created automatically. I don't like the idea of manual configuration as it provides invalid description of actual transport parameters in most circumstances. We are providing either standard socket transport or (if configured) SSL transport. Currently user is responsible for providing transport description. So if for example user configures SSL transport but doesn't change transport config then transport description in ior settings is invalid. What is more transport config is currently used to configure required SSL connection - that is if user wants to configure SSL connection he has to specify at least one SSL related transport field as required. This is imo inelegant and not much user friendly. I propose the following change: transport config is created automatically. If user configures SSL then all transport fields provided by SSL (f.e. confidentiality) will be set as supported. I also introduction of boolean field server-requires-ssl in security tag. If this field is set to true, then all SSL transport fields will be set as required. )
> Automatic creation of transport config in IOR settings
> ------------------------------------------------------
>
> Key: WFLY-6642
> URL: https://issues.jboss.org/browse/WFLY-6642
> Project: WildFly
> Issue Type: Enhancement
> Components: IIOP
> Affects Versions: 10.0.0.Final
> Reporter: Tomasz Adamski
> Assignee: Tomasz Adamski
> Priority: Minor
>
> I propose that the transport config parameters configured in ior settings, which later are present in the description of all corba object IORs created in the server, are created automatically. I don't like the idea of manual configuration as it provides invalid description of actual transport parameters in most circumstances. We are providing either standard socket transport or (if configured) SSL transport. Currently user is responsible for providing transport description. So if for example user configures SSL transport but doesn't change transport config then transport description in ior settings is invalid. What is more transport config is currently used to configure required SSL connection - that is if user wants to configure SSL connection he has to specify at least one SSL related transport field as required. This is imo inelegant and not much user friendly. I propose the following change: transport config is created automatically. If user configures SSL then all transport fields provided by SSL (f.e. confidentiality) will be set as supported. To configure required ssl connections server-requires-ssl field in security tag is introduced. If this field is set to true, then all SSL transport fields will be set as required.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6642) Automatic creation of transport config in IOR settings
by Tomasz Adamski (JIRA)
[ https://issues.jboss.org/browse/WFLY-6642?page=com.atlassian.jira.plugin.... ]
Tomasz Adamski updated WFLY-6642:
---------------------------------
Description: I propose that the transport config parameters configured in ior settings, which later are present in the description of all corba object IORs created in the server, are created automatically. I don't like the idea of manual configuration as it provides invalid description of actual transport parameters in most circumstances. We are providing either standard socket transport or (if configured) SSL transport. Currently user is responsible for providing transport description. So if for example user configures SSL transport but doesn't change transport config then transport description in ior settings is invalid. What is more transport config is currently used to configure required SSL connection - that is if user wants to configure SSL connection he has to specify at least one SSL related transport field as required. This is imo inelegant and not much user friendly. I propose the following change: transport config is created automatically. If user configures SSL then all transport fields provided by SSL (f.e. confidentiality) will be set as supported. I also introduction of boolean field server-requires-ssl in security tag. If this field is set to true, then all SSL transport fields will be set as required. (was: I propose that the transport config parameters configured in ior settings, which later are present in the description of all corba object IORs created in the server, are created automatically. I don't like the idea of manual configuration as it provides invalid description of actual transport parameters in most circumstances. We are providing either standard socket transport or (if configured) SSL transport. Currently user is responsible for providing transport description. So if for example user configures SSL transport but doesn't change transport config then transport description in ior settings is invalid. What is more transport config is currently used to configure required SSL connection - that is if user wants to configure SSL connection he has to specify at least one SSL related transport field as required. This is imo inelegant and not much user friendly. I propose the following change: transport config is created automatically. If user configures SSL then all transport fields provided by SSL (f.e. confidentiality) will be set as supported. I also introduction of boolean field server-requires-ssl in security tag. If this field is set to true, then we are )
> Automatic creation of transport config in IOR settings
> ------------------------------------------------------
>
> Key: WFLY-6642
> URL: https://issues.jboss.org/browse/WFLY-6642
> Project: WildFly
> Issue Type: Enhancement
> Components: IIOP
> Affects Versions: 10.0.0.Final
> Reporter: Tomasz Adamski
> Assignee: Tomasz Adamski
> Priority: Minor
>
> I propose that the transport config parameters configured in ior settings, which later are present in the description of all corba object IORs created in the server, are created automatically. I don't like the idea of manual configuration as it provides invalid description of actual transport parameters in most circumstances. We are providing either standard socket transport or (if configured) SSL transport. Currently user is responsible for providing transport description. So if for example user configures SSL transport but doesn't change transport config then transport description in ior settings is invalid. What is more transport config is currently used to configure required SSL connection - that is if user wants to configure SSL connection he has to specify at least one SSL related transport field as required. This is imo inelegant and not much user friendly. I propose the following change: transport config is created automatically. If user configures SSL then all transport fields provided by SSL (f.e. confidentiality) will be set as supported. I also introduction of boolean field server-requires-ssl in security tag. If this field is set to true, then all SSL transport fields will be set as required.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6642) Automatic creation of transport config in IOR settings
by Tomasz Adamski (JIRA)
[ https://issues.jboss.org/browse/WFLY-6642?page=com.atlassian.jira.plugin.... ]
Tomasz Adamski updated WFLY-6642:
---------------------------------
Description: I propose that the transport config parameters configured in ior settings, which later are present in the description of all corba object IORs created in the server, are created automatically. I don't like the idea of manual configuration as it provides invalid description of actual transport parameters in most circumstances. We are providing either standard socket transport or (if configured) SSL transport. Currently user is responsible for providing transport description. So if for example user configures SSL transport but doesn't change transport config then transport description in ior settings is invalid. What is more transport config is currently used to configure required SSL connection - that is if user wants to configure SSL connection he has to specify at least one SSL related transport field as required. This is imo inelegant and not much user friendly. I propose the following change: transport config is created automatically. If user configures SSL then all transport fields provided by SSL (f.e. confidentiality) will be set as supported. I also introduction of boolean field server-requires-ssl in security tag. If this field is set to true, then we are
> Automatic creation of transport config in IOR settings
> ------------------------------------------------------
>
> Key: WFLY-6642
> URL: https://issues.jboss.org/browse/WFLY-6642
> Project: WildFly
> Issue Type: Enhancement
> Components: IIOP
> Affects Versions: 10.0.0.Final
> Reporter: Tomasz Adamski
> Assignee: Tomasz Adamski
> Priority: Minor
>
> I propose that the transport config parameters configured in ior settings, which later are present in the description of all corba object IORs created in the server, are created automatically. I don't like the idea of manual configuration as it provides invalid description of actual transport parameters in most circumstances. We are providing either standard socket transport or (if configured) SSL transport. Currently user is responsible for providing transport description. So if for example user configures SSL transport but doesn't change transport config then transport description in ior settings is invalid. What is more transport config is currently used to configure required SSL connection - that is if user wants to configure SSL connection he has to specify at least one SSL related transport field as required. This is imo inelegant and not much user friendly. I propose the following change: transport config is created automatically. If user configures SSL then all transport fields provided by SSL (f.e. confidentiality) will be set as supported. I also introduction of boolean field server-requires-ssl in security tag. If this field is set to true, then we are
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-429) Incremental redeployment (single file update) over management API
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-429?page=com.atlassian.jira.plugin... ]
ehsavoie Hugonnet reassigned WFCORE-429:
----------------------------------------
Assignee: ehsavoie Hugonnet
> Incremental redeployment (single file update) over management API
> -----------------------------------------------------------------
>
> Key: WFCORE-429
> URL: https://issues.jboss.org/browse/WFCORE-429
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI, Domain Management
> Reporter: Ondrej Zizka
> Assignee: ehsavoie Hugonnet
> Labels: deploy, deployment, incremental, redeployment
> Fix For: 3.0.0.Beta1
>
>
> (Based on JBDS use case - see EAP6-1)
> See also https://mojo.redhat.com/docs/DOC-934058 for notes
> By incremental redeployment, we mean the situation when something is deployed, and after changes (in IDE e.g.), only that single file (.jsp, .xml, .class) would be re-deployed to the server, *over management API* - which is, you'd give it a stream and a path where it belongs in the deployment, and the operation would accept that file and put it to the right place in VFS, clear caches etc.
> Use cases:
> Big .war's, mainly on remote
> Cloud deployments
> Also, you loose sessions etc.
> "JSP recompile on file update" - mgmt API operation - added in WildFly 8?
> Not expected to work in domain mode.
> Stuart said that session persistence is implemented in WFly 8, but not the incremental redeployment.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6680) :read-proxies-configuration and :read-proxies-info fail when there is no httpd
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6680?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-6680:
---------------------------------
Affects Version/s: 10.0.0.Final
> :read-proxies-configuration and :read-proxies-info fail when there is no httpd
> ------------------------------------------------------------------------------
>
> Key: WFLY-6680
> URL: https://issues.jboss.org/browse/WFLY-6680
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.0.0.Final
> Environment: RHEL 6, EAP 6.1.0, mod_cluster-1.2.4-1.Final_redhat_1.ep6.el6.noarch,
> Reporter: Kristina Clair
> Assignee: Radoslav Husar
>
> When the modcluster subsystem is unable to connect to a proxy, the jboss-cli commands :read-proxies-configuration and :read-proxies-info fail with an unhelpful error.
> On both the domain controller and application host, :read-proxies-info and :read-proxies-configuration fail with the same error. This is the output from the application host:
> {noformat}
> [domain@localhost:9999 subsystem=modcluster] pwd
> /host=localhost/server=cluster2/subsystem=modcluster
> [domain@localhost:9999 subsystem=modcluster] :list-proxies
> {
> "outcome" => "success",
> "result" => [
> "web02:8009",
> "web01:8009"
> ]
> }
> [domain@localhost:9999 subsystem=modcluster] :read-proxies-configuration
> {
> "outcome" => "failed",
> "result" => undefined,
> "failure-description" => "JBAS014749: Operation handler failed: newValue is null",
> "rolled-back" => true
> }
> [domain@localhost:9999 subsystem=modcluster] :read-proxies-info
> {
> "outcome" => "failed",
> "result" => undefined,
> "failure-description" => "JBAS014749: Operation handler failed: newValue is null",
> "rolled-back" => true
> }
> {noformat}
> In the above example, modcluster was not able to connect to the proxies due to an ssl misconfiguration in the modcluster subsystem in domain.xml.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6680) :read-proxies-configuration and :read-proxies-info fail when there is no httpd
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6680?page=com.atlassian.jira.plugin.... ]
Radoslav Husar moved MODCLUSTER-346 to WFLY-6680:
-------------------------------------------------
Project: WildFly (was: mod_cluster)
Key: WFLY-6680 (was: MODCLUSTER-346)
Affects Version/s: (was: 1.2.4.Final)
> :read-proxies-configuration and :read-proxies-info fail when there is no httpd
> ------------------------------------------------------------------------------
>
> Key: WFLY-6680
> URL: https://issues.jboss.org/browse/WFLY-6680
> Project: WildFly
> Issue Type: Bug
> Environment: RHEL 6, EAP 6.1.0, mod_cluster-1.2.4-1.Final_redhat_1.ep6.el6.noarch,
> Reporter: Kristina Clair
> Assignee: Radoslav Husar
>
> When the modcluster subsystem is unable to connect to a proxy, the jboss-cli commands :read-proxies-configuration and :read-proxies-info fail with an unhelpful error.
> On both the domain controller and application host, :read-proxies-info and :read-proxies-configuration fail with the same error. This is the output from the application host:
> {noformat}
> [domain@localhost:9999 subsystem=modcluster] pwd
> /host=localhost/server=cluster2/subsystem=modcluster
> [domain@localhost:9999 subsystem=modcluster] :list-proxies
> {
> "outcome" => "success",
> "result" => [
> "web02:8009",
> "web01:8009"
> ]
> }
> [domain@localhost:9999 subsystem=modcluster] :read-proxies-configuration
> {
> "outcome" => "failed",
> "result" => undefined,
> "failure-description" => "JBAS014749: Operation handler failed: newValue is null",
> "rolled-back" => true
> }
> [domain@localhost:9999 subsystem=modcluster] :read-proxies-info
> {
> "outcome" => "failed",
> "result" => undefined,
> "failure-description" => "JBAS014749: Operation handler failed: newValue is null",
> "rolled-back" => true
> }
> {noformat}
> In the above example, modcluster was not able to connect to the proxies due to an ssl misconfiguration in the modcluster subsystem in domain.xml.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6678) StackoverflowError ejbclientinvocationcontext
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-6678?page=com.atlassian.jira.plugin.... ]
David Lloyd commented on WFLY-6678:
-----------------------------------
Hmm I can't explain where the stack frames went in that case. Looking at the logger code, the default is "unlimited", and there is nothing in the JDK to limit it either that I can find.
> StackoverflowError ejbclientinvocationcontext
> ---------------------------------------------
>
> Key: WFLY-6678
> URL: https://issues.jboss.org/browse/WFLY-6678
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Environment: wildfly 9.0.1, jdk 1.8
> Reporter: Jimmy Pannier
> Attachments: server.log
>
>
> Sometimes after few days i get an exception
> Here is a stacktrace.
> 2016-06-07 07:38:10,441 ERROR [org.jboss.as.ejb3.invocation] (default task-76) WFLYEJB0034: EJB Invocation failed on component StorageServiceImpl for method public abstract java.util.List com.inovelan.cloud.api.storage.service.dataset.IStorageEjbService.loadData(com.inovelan.cloud.api.storage.model.dto.dataset.LoadDataConfig): javax.ejb.EJBTransactionRolledbackException: WFLYEJB0457: Unexpected Error
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleInCallerTx(CMTTxInterceptor.java:153)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:256)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:329)
> .....
> Caused by: java.lang.StackOverflowError
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at com.inovelan.cloud.common.proxy.ProxyInterceptor.handleInvocationResult(ProxyInterceptor.java:37)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at com.inovelan.cloud.common.proxy.ProxyInterceptor.handleInvocationResult(ProxyInterceptor.java:37)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at com.inovelan.cloud.common.proxy.ProxyInterceptor.handleInvocationResult(ProxyInterceptor.java:37)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at com.inovelan.cloud.common.proxy.ProxyInterceptor.handleInvocationResult(ProxyInterceptor.java:37)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at com.inovelan.cloud.common.proxy.ProxyInterceptor.handleInvocationResult(ProxyInterceptor.java:37)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at com.inovelan.cloud.common.proxy.ProxyInterceptor.handleInvocationResult(ProxyInterceptor.java:37)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at com.inovelan.cloud.common.proxy.ProxyInterceptor.handleInvocationResult(ProxyInterceptor.java:37)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at com.inovelan.cloud.common.proxy.ProxyInterceptor.handleInvocationResult(ProxyInterceptor.java:37)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at com.inovelan.cloud.common.proxy.ProxyInterceptor.handleInvocationResult(ProxyInterceptor.java:37)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at com.inovelan.cloud.common.proxy.ProxyInterceptor.handleInvocationResult(ProxyInterceptor.java:37)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at com.inovelan.cloud.common.proxy.ProxyInterceptor.handleInvocationResult(ProxyInterceptor.java:37)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months