[JBoss JIRA] (WFLY-4769) WildFly 8 and 9. Connecting to topic using http-remoting and JNDI fails when server is behind NAT firewall
by jukka sirviö (JIRA)
[ https://issues.jboss.org/browse/WFLY-4769?page=com.atlassian.jira.plugin.... ]
jukka sirviö edited comment on WFLY-4769 at 4/20/16 2:09 AM:
-------------------------------------------------------------
George:
Please see this "original" forum reference:
https://developer.jboss.org/message/933327#933327
At least this is working for me, Please mark the forum reference also as "answered" if this fixes your NAT issue. In Wildfly 10.x the code is a bit different because of ArtemisMQ, please let me know if you need further assistance for 10.x.
Kindly, Jukka
was (Author: jukka.sirvio):
George:
Please see this "original" forum reference:
https://developer.jboss.org/message/933327#933327
At least this is working for me, Please mark the forum reference also as "answered" if this fixes your NAT issue.
Kindly, Jukka
> WildFly 8 and 9. Connecting to topic using http-remoting and JNDI fails when server is behind NAT firewall
> -----------------------------------------------------------------------------------------------------------
>
> Key: WFLY-4769
> URL: https://issues.jboss.org/browse/WFLY-4769
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 8.2.0.Final, 9.0.0.CR1, 10.0.0.Final
> Environment: RedHat7
> Reporter: George Turner
> Assignee: Jeff Mesnil
>
> Server is behind NAT firewall. Client code:
> Properties topicProperties = new Properties();
> topicProperties.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory");
> topicProperties.put(Context.PROVIDER_URL, "http-remoting://" + host + ":" + port);
> InitialContext ctx = new InitialContext(topicProperties);
> ConnectionFactory tmp = (ConnectionFactory) topicCtx.lookup("jms/RemoteConnectionFactory");
> connection = tmp.createConnection();
> Jun 11, 2015 8:26:07 AM org.xnio.Xnio <clinit>
> INFO: XNIO version 3.3.1.Final
> Jun 11, 2015 8:26:07 AM org.xnio.nio.NioXnio <clinit>
> INFO: XNIO NIO Implementation Version 3.3.1.Final
> Jun 11, 2015 8:26:07 AM org.jboss.remoting3.EndpointImpl <clinit>
> INFO: JBoss Remoting version 4.0.9.Final
> javax.jms.JMSException: Failed to create session factory
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnectionInternal(HornetQConnectionFactory.java:673)
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnection(HornetQConnectionFactory.java:112)
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnection(HornetQConnectionFactory.java:107)
> at com.lmco.spacefence.netcentric.test.client.TestMessageConsumer.<init>(TestMessageConsumer.java:36)
> at com.lmco.spacefence.netcentric.test.client.TestMessageConsumer.main(TestMessageConsumer.java:24)
> Caused by: HornetQNotConnectedException[errorType=NOT_CONNECTED message=HQ119007: Cannot connect to server(s). Tried with all available servers.]
> at org.hornetq.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:905)
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnectionInternal(HornetQConnectionFactory.java:669)
> ... 4 more
> Disconnected from the target VM, address: '127.0.0.1:54275', transport: 'socket'
>
> Client debugger shows the ConnectionFactory instance returned:
> initialConnectors = {org.hornetq.api.core.TransportConfiguration[1]@2183}
> 0 = {org.hornetq.api.core.TransportConfiguration@2196} "TransportConfiguration(name=http-connector, factory=org-hornetq-core-remoting-impl-netty-NettyConnectorFactory) ?port=8080&host=10-10-20-77&http-upgrade-enabled=true&http-upgrade-endpoint=http-acceptor"
> name = {java.lang.String@2198} "http-connector"
> factoryClassName = {java.lang.String@2199} "org.hornetq.core.remoting.impl.netty.NettyConnectorFactory"
> params = {java.util.HashMap@2200} size = 4
> 0 = {java.util.HashMap$Node@2203} "port" -> "8080"
> 1 = {java.util.HashMap$Node@2204} "host" -> "10.10.20.77"
> 2 = {java.util.HashMap$Node@2205} "http-upgrade-enabled" -> "true"
> 3 = {java.util.HashMap$Node@2206} "http-upgrade-endpoint" -> "http-acceptor"
> 10.10.20.77 is IP address of server behind firewall, NOT the IP address used by the client.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-4769) WildFly 8 and 9. Connecting to topic using http-remoting and JNDI fails when server is behind NAT firewall
by jukka sirviö (JIRA)
[ https://issues.jboss.org/browse/WFLY-4769?page=com.atlassian.jira.plugin.... ]
jukka sirviö edited comment on WFLY-4769 at 4/20/16 2:08 AM:
-------------------------------------------------------------
George:
Please see this "original" forum reference:
https://developer.jboss.org/message/933327#933327
At least this is working for me, Please mark the forum reference also as "answered" if this fixes your NAT issue.
Kindly, Jukka
was (Author: jukka.sirvio):
Please see this "original" forum reference:
https://developer.jboss.org/message/933327#933327
> WildFly 8 and 9. Connecting to topic using http-remoting and JNDI fails when server is behind NAT firewall
> -----------------------------------------------------------------------------------------------------------
>
> Key: WFLY-4769
> URL: https://issues.jboss.org/browse/WFLY-4769
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 8.2.0.Final, 9.0.0.CR1, 10.0.0.Final
> Environment: RedHat7
> Reporter: George Turner
> Assignee: Jeff Mesnil
>
> Server is behind NAT firewall. Client code:
> Properties topicProperties = new Properties();
> topicProperties.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory");
> topicProperties.put(Context.PROVIDER_URL, "http-remoting://" + host + ":" + port);
> InitialContext ctx = new InitialContext(topicProperties);
> ConnectionFactory tmp = (ConnectionFactory) topicCtx.lookup("jms/RemoteConnectionFactory");
> connection = tmp.createConnection();
> Jun 11, 2015 8:26:07 AM org.xnio.Xnio <clinit>
> INFO: XNIO version 3.3.1.Final
> Jun 11, 2015 8:26:07 AM org.xnio.nio.NioXnio <clinit>
> INFO: XNIO NIO Implementation Version 3.3.1.Final
> Jun 11, 2015 8:26:07 AM org.jboss.remoting3.EndpointImpl <clinit>
> INFO: JBoss Remoting version 4.0.9.Final
> javax.jms.JMSException: Failed to create session factory
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnectionInternal(HornetQConnectionFactory.java:673)
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnection(HornetQConnectionFactory.java:112)
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnection(HornetQConnectionFactory.java:107)
> at com.lmco.spacefence.netcentric.test.client.TestMessageConsumer.<init>(TestMessageConsumer.java:36)
> at com.lmco.spacefence.netcentric.test.client.TestMessageConsumer.main(TestMessageConsumer.java:24)
> Caused by: HornetQNotConnectedException[errorType=NOT_CONNECTED message=HQ119007: Cannot connect to server(s). Tried with all available servers.]
> at org.hornetq.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:905)
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnectionInternal(HornetQConnectionFactory.java:669)
> ... 4 more
> Disconnected from the target VM, address: '127.0.0.1:54275', transport: 'socket'
>
> Client debugger shows the ConnectionFactory instance returned:
> initialConnectors = {org.hornetq.api.core.TransportConfiguration[1]@2183}
> 0 = {org.hornetq.api.core.TransportConfiguration@2196} "TransportConfiguration(name=http-connector, factory=org-hornetq-core-remoting-impl-netty-NettyConnectorFactory) ?port=8080&host=10-10-20-77&http-upgrade-enabled=true&http-upgrade-endpoint=http-acceptor"
> name = {java.lang.String@2198} "http-connector"
> factoryClassName = {java.lang.String@2199} "org.hornetq.core.remoting.impl.netty.NettyConnectorFactory"
> params = {java.util.HashMap@2200} size = 4
> 0 = {java.util.HashMap$Node@2203} "port" -> "8080"
> 1 = {java.util.HashMap$Node@2204} "host" -> "10.10.20.77"
> 2 = {java.util.HashMap$Node@2205} "http-upgrade-enabled" -> "true"
> 3 = {java.util.HashMap$Node@2206} "http-upgrade-endpoint" -> "http-acceptor"
> 10.10.20.77 is IP address of server behind firewall, NOT the IP address used by the client.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-4769) WildFly 8 and 9. Connecting to topic using http-remoting and JNDI fails when server is behind NAT firewall
by jukka sirviö (JIRA)
[ https://issues.jboss.org/browse/WFLY-4769?page=com.atlassian.jira.plugin.... ]
jukka sirviö commented on WFLY-4769:
------------------------------------
Please see this "original" forum reference:
https://developer.jboss.org/message/933327#933327
> WildFly 8 and 9. Connecting to topic using http-remoting and JNDI fails when server is behind NAT firewall
> -----------------------------------------------------------------------------------------------------------
>
> Key: WFLY-4769
> URL: https://issues.jboss.org/browse/WFLY-4769
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 8.2.0.Final, 9.0.0.CR1, 10.0.0.Final
> Environment: RedHat7
> Reporter: George Turner
> Assignee: Jeff Mesnil
>
> Server is behind NAT firewall. Client code:
> Properties topicProperties = new Properties();
> topicProperties.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory");
> topicProperties.put(Context.PROVIDER_URL, "http-remoting://" + host + ":" + port);
> InitialContext ctx = new InitialContext(topicProperties);
> ConnectionFactory tmp = (ConnectionFactory) topicCtx.lookup("jms/RemoteConnectionFactory");
> connection = tmp.createConnection();
> Jun 11, 2015 8:26:07 AM org.xnio.Xnio <clinit>
> INFO: XNIO version 3.3.1.Final
> Jun 11, 2015 8:26:07 AM org.xnio.nio.NioXnio <clinit>
> INFO: XNIO NIO Implementation Version 3.3.1.Final
> Jun 11, 2015 8:26:07 AM org.jboss.remoting3.EndpointImpl <clinit>
> INFO: JBoss Remoting version 4.0.9.Final
> javax.jms.JMSException: Failed to create session factory
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnectionInternal(HornetQConnectionFactory.java:673)
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnection(HornetQConnectionFactory.java:112)
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnection(HornetQConnectionFactory.java:107)
> at com.lmco.spacefence.netcentric.test.client.TestMessageConsumer.<init>(TestMessageConsumer.java:36)
> at com.lmco.spacefence.netcentric.test.client.TestMessageConsumer.main(TestMessageConsumer.java:24)
> Caused by: HornetQNotConnectedException[errorType=NOT_CONNECTED message=HQ119007: Cannot connect to server(s). Tried with all available servers.]
> at org.hornetq.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:905)
> at org.hornetq.jms.client.HornetQConnectionFactory.createConnectionInternal(HornetQConnectionFactory.java:669)
> ... 4 more
> Disconnected from the target VM, address: '127.0.0.1:54275', transport: 'socket'
>
> Client debugger shows the ConnectionFactory instance returned:
> initialConnectors = {org.hornetq.api.core.TransportConfiguration[1]@2183}
> 0 = {org.hornetq.api.core.TransportConfiguration@2196} "TransportConfiguration(name=http-connector, factory=org-hornetq-core-remoting-impl-netty-NettyConnectorFactory) ?port=8080&host=10-10-20-77&http-upgrade-enabled=true&http-upgrade-endpoint=http-acceptor"
> name = {java.lang.String@2198} "http-connector"
> factoryClassName = {java.lang.String@2199} "org.hornetq.core.remoting.impl.netty.NettyConnectorFactory"
> params = {java.util.HashMap@2200} size = 4
> 0 = {java.util.HashMap$Node@2203} "port" -> "8080"
> 1 = {java.util.HashMap$Node@2204} "host" -> "10.10.20.77"
> 2 = {java.util.HashMap$Node@2205} "http-upgrade-enabled" -> "true"
> 3 = {java.util.HashMap$Node@2206} "http-upgrade-endpoint" -> "http-acceptor"
> 10.10.20.77 is IP address of server behind firewall, NOT the IP address used by the client.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6501) EJB with AroundConstruct interceptor with Object return type fails to deploy
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/WFLY-6501?page=com.atlassian.jira.plugin.... ]
Tomas Remes commented on WFLY-6501:
-----------------------------------
Yes the names are little bit weird. You could use my test but nevermind. I would use something like {{AroundConstructInterceptorWithObjectReturnType}} and {{SessionBeanWithInterceptor}}. There is now no need to fix this in Weld because currently there is no way how to distinguish whether the class is only bean or the interceptor class in case of using {{@Interceptors}}.
> EJB with AroundConstruct interceptor with Object return type fails to deploy
> ----------------------------------------------------------------------------
>
> Key: WFLY-6501
> URL: https://issues.jboss.org/browse/WFLY-6501
> Project: WildFly
> Issue Type: Bug
> Components: EE, EJB
> Affects Versions: 10.0.0.Final
> Reporter: Tomas Remes
> Assignee: Dmitrii Tikhomirov
> Attachments: myintercepter.tar.gz
>
>
> Having:
> {code}
> @Stateless
> @Interceptors(AroundConstructInterceptor.class)
> public class AroundConstructSLSB {
> ...
> }
> {code}
> and
> {code}
> public class AroundConstructInterceptor {
> public static volatile boolean intercepted = false;
> @AroundConstruct
> private Object aroundConstruct(InvocationContext ctx) throws Exception {
> intercepted = true;
> return ctx.proceed();
> }
> }
> {code}
> fails with following exception:
> {noformat}
> 08:18:55,464 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.unit."bcc899ab-39cf-44dc-a2ba-e364d53091cc.war".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."bcc899ab-39cf-44dc-a2ba-e364d53091cc.war".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of deployment "bcc899ab-39cf-44dc-a2ba-e364d53091cc.war"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> 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)
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYEE0024: Could not configure component AroundConstructSLSB
> at org.jboss.as.ee.component.deployers.EEModuleConfigurationProcessor.deploy(EEModuleConfigurationProcessor.java:96)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
> ... 5 more
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYSRV0175: No method found with id: Method aroundConstruct(javax.interceptor.InvocationContext) on class (or its super class) class org.jboss.as.test.integration.ejb.interceptor.aroundconstruct.returnObject.AroundConstructInterceptor
> at org.jboss.as.server.deployment.reflect.ClassReflectionIndexUtil.findRequiredMethod(ClassReflectionIndexUtil.java:79)
> at org.jboss.as.ee.component.DefaultInterceptorConfigurator$1.handleInterceptorClass(DefaultInterceptorConfigurator.java:177)
> at org.jboss.as.ee.component.DefaultInterceptorConfigurator$1.handle(DefaultInterceptorConfigurator.java:158)
> at org.jboss.as.ee.component.ClassDescriptionTraversal.run(ClassDescriptionTraversal.java:54)
> at org.jboss.as.ee.component.DefaultInterceptorConfigurator.configure(DefaultInterceptorConfigurator.java:188)
> at org.jboss.as.ee.component.deployers.EEModuleConfigurationProcessor.deploy(EEModuleConfigurationProcessor.java:82)
> ... 6 more
> {noformat}
> I cannot see any statement in Interceptor spec forbidding this. Testcase is available at https://github.com/tremes/wildfly/tree/intercept_ejb. I think the problem is class description having this method return type as void. I guess it occurs at first at https://github.com/wildfly/wildfly/blob/master/ee/src/main/java/org/jboss...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JGRP-1903) TCPPING: discovery dissemination for static discovery protocols
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1903?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1903 at 4/20/16 1:38 AM:
---------------------------------------------------------
The _coordinator_ (only) does the following on a view change (if discovery dissemination is enabled and discovery protocol is static):
* Determines the set of new members N and left members L
* Sends information about everyone except self and L to N
* Sends information about N to everyone except self and L
There should also be a JMX exposed operation which sends information about everyone to everyone (except self).
To enable JGRP-1903, set {{TCPPING.send_cache_on_join}} to true (default: false).
was (Author: belaban):
The _coordinator_ (only) does the following on a view change (if discovery dissemination is enabled and discovery protocol is static):
* Determines the set of new members N and left members L
* Sends information about everyone except self and L to N
* Sends information about N to everyone except self and L
There should also be a JMX exposed operation which sends information about everyone to everyone (except self)
> TCPPING: discovery dissemination for static discovery protocols
> ---------------------------------------------------------------
>
> Key: JGRP-1903
> URL: https://issues.jboss.org/browse/JGRP-1903
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.1
>
>
> For {{TCPPING}}, usually all members have to be listed in {{initial_hosts}}. If we don't know all of the members up front, we could have the coordinator disseminate the IP address and port information dynamically.
> Say {{TCPPING.initial_hosts}} only lists A (the coord). When members B, C, D and E join (in that order), we have the following caches:
> |A|B|C|D|E|
> |ABCDE|AB|AC|AD|AE|
> Every member has information about itself and A, but not about other members. So, for example, D won't be able to send a unicast to C, and vice versa. Or, when E sends a multicast, it would only be delivered to itself and A, but not to B, C and D.
> h5. Solution
> * When we have a static discovery layer, have the coordinator broadcast its cache information to the rest of the cluster
> * This can be done when a new member join, or periodically, or upon request (JMX)
> * Should be goverened by a property: if someone lists all members in {{initial_hosts}}, then he may want to turn this off
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFCORE-974) Cli calls leak memory in Host Controller when reading children names in domain mode
by Paul Roesler (JIRA)
[ https://issues.jboss.org/browse/WFCORE-974?page=com.atlassian.jira.plugin... ]
Paul Roesler commented on WFCORE-974:
-------------------------------------
I noticed the zabbix monitoring on the Host Controller png. Could someone provide the template or the URL to the template to monitor this? The work around has worked splendidly however I would like to get this monitored in my zabbix as well. This would be very helpful to our group as well.
> Cli calls leak memory in Host Controller when reading children names in domain mode
> -----------------------------------------------------------------------------------
>
> Key: WFCORE-974
> URL: https://issues.jboss.org/browse/WFCORE-974
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Remoting
> Environment: CentOS 6.5:
> # java -version
> java version "1.7.0_79"
> OpenJDK Runtime Environment (rhel-2.5.5.2.el7_1-x86_64 u79-b14)
> OpenJDK 64-Bit Server VM (build 24.79-b02, mixed mode)
> CentOS 7.0:
> # java -version
> java version "1.7.0_80"
> Java(TM) SE Runtime Environment (build 1.7.0_80-b15)
> Java HotSpot(TM) 64-Bit Server VM (build 24.80-b11, mixed mode)
> Reporter: Michael Noack
> Assignee: David Lloyd
> Priority: Critical
> Fix For: 2.0.0.Beta7
>
> Attachments: host-controller-jvm.png
>
>
> Calling the cli using the command:
> {{jboss-cli.sh --connect --user="myuser" --password="mypassword" --command=":read-children-names(child-type=host)"}}
> leaks memory to old gen. Eventually the host controller goes OOM if called to often.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFCORE-1484) Management notifications when destabilizing MSC and after it stabilizes
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1484:
----------------------------------------
Summary: Management notifications when destabilizing MSC and after it stabilizes
Key: WFCORE-1484
URL: https://issues.jboss.org/browse/WFCORE-1484
Project: WildFly Core
Issue Type: Feature Request
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
The OC should emit a management notification before the first action an op takes that may destabilize MSC, and then if it emits the first, it should emit another once MSC stabilizes.
These would be emitted directly by the OC, not queued with the OSH-submitted ones that only go out in Stage.DONE if the op succeeded.
Equivalent things need to be done during rollback.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6538) https-listener does not support proxy-address-forwarding
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-6538?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-6538:
--------------------------------------
It is safe to use with HTTPS
> https-listener does not support proxy-address-forwarding
> --------------------------------------------------------
>
> Key: WFLY-6538
> URL: https://issues.jboss.org/browse/WFLY-6538
> Project: WildFly
> Issue Type: Feature Request
> Components: Web (Undertow)
> Affects Versions: 9.0.2.Final, 10.0.0.Final
> Reporter: Emond Papegaaij
> Assignee: Tomaz Cerar
>
> HttpsListenerService explicitly passes false to its superclass for proxyAddressForwarding and certificateForwarding, making it impossible to enable these features. For a security-sensitive application, we need a secure connection from our proxy to WildFly and we need WildFly to respect the headers sent by our proxy. It seems easy to support these options by reading them in HttpsListenerAdd and passing them to HttpsListenerService, which can simply pass them to the super constructor.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (ELY-497) Lazy scope creation
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-497?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-497:
---------------------------------
Summary: Lazy scope creation (was: Lazt scope creation)
> Lazy scope creation
> -------------------
>
> Key: ELY-497
> URL: https://issues.jboss.org/browse/ELY-497
> Project: WildFly Elytron
> Issue Type: Feature Request
> Components: HTTP
> Reporter: Darran Lofthouse
> Priority: Critical
> Fix For: 1.1.0.CR1
>
>
> It is not confirmed that we will do this but if we want to support lazy creation of scoped e.g. session scoped then we need to do it now or adding later may become a compatibility problem.
> We could add methods to check if one exists and a method to create it - or we could wait until the firs attachment is added - or other options.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years