[JBoss JIRA] (WFCORE-3049) JBoss CLI - CJK Character Issue
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3049?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise commented on WFCORE-3049:
----------------------------------------------
[~jprasanna], do we have news on this one? Did UTF-8 encoding of the file fixed your problem?
Thanks.
> JBoss CLI - CJK Character Issue
> -------------------------------
>
> Key: WFCORE-3049
> URL: https://issues.jboss.org/browse/WFCORE-3049
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: J Prasanna Venkatesan
> Assignee: Jean-Francois Denise
> Labels: cjk, login-module
> Attachments: cjk2.cli
>
>
> Dear All,
>
> Environment:
>
> CentOS Linux release 7.1.1503 (Core)
> /usr/java/jdk1.8.0_45/
> WildFly 8.2.0
> I am executing few LoginModule commands using file. My file name is command.cli
> Its content is
>
> {color:red}[root@cu490 temp]# cat command.cli
> /subsystem=security/security-domain=SourceForge/authentication=classic/login-module=org.jboss.security.auth.spi.LdapExtLoginModule3:add(code=org.jboss.security.auth.spi.LdapExtLoginModule, flag=sufficient, module-options={ "java.naming.provider.url" => "ldap://a.com:389/", "java.naming.referral" => "follow", "java.naming.factory.initial" => "com.sun.jndi.ldap.LdapCtxFactory", "java.naming.security.authentication" => "simple", "bindDN" => "cn=in00655,OU=비임직원,OU=SK이노베이션,DC=test,DC=net", "bindCredential" => "xxxxxx", "baseCtxDN" => "ou=SK이노베이션,DC=test,DC=net", "baseFilter" => "(sAMAccountName={0})", "roleAttributeID" => "memberOf", "roleAttributeIsDN" => "true", "rolesCtxDN" => "DC=test,DC=net", "roleFilter" => "(member={1})", "roleRecursion" => "1", "searchTimeLimit" => "5000", "searchScope" => "SUBTREE_SCOPE", "allowEmptyPasswords" => "false", "throwValidateError" => "true" }){allow-resource-service-restart=true}
>
> [root@cu490 temp]# /opt/collabnet/teamforge/runtime/jboss/bin/jboss-cli.sh --connect --file=command.cli
> {
> "outcome" => "success",
> "response-headers" => {"process-state" => "reload-required"}
> }
> [root@cu490 temp]# vim /opt/collabnet/teamforge//runtime/jboss/standalone/configuration/standalone-full.xml{color}
>
> Content inside standalone-full.xml is
>
> {color:red}<login-module name="org.jboss.security.auth.spi.LdapExtLoginModule3" code="org.jboss.security.auth.spi.LdapExtLoginModule" flag="sufficient">
> <module-option name="java.naming.provider.url" value="ldap://a.com:389/"/>
> <module-option name="java.naming.referral" value="follow"/>
> <module-option name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory"/>
> <module-option name="java.naming.security.authentication" value="simple"/>
> <module-option name="bindDN" value="cn=in00655,OU=????,OU=SK?????,DC=test,DC=net"/>
> <module-option name="bindCredential" value="xxxxxx"/>
> <module-option name="baseCtxDN" value="ou=SK?????,DC=test,DC=net"/>
> <module-option name="baseFilter" value="(sAMAccountName={0})"/>
> <module-option name="roleAttributeID" value="memberOf"/>
> <module-option name="roleAttributeIsDN" value="true"/>
> <module-option name="rolesCtxDN" value="DC=test,DC=net"/>
> <module-option name="roleFilter" value="(member={1})"/>
> <module-option name="roleRecursion" value="1"/>
> <module-option name="searchTimeLimit" value="5000"/>
> <module-option name="searchScope" value="SUBTREE_SCOPE"/>
> <module-option name="allowEmptyPasswords" value="false"/>
> <module-option name="throwValidateError" value="true"/>
> </login-module>{color}
>
> You can see instead of CJK characters we are seeing ??? in standalone-full.xml
>
> Please throw some light on this.
>
> Thanks & Regards,
> J Prasanna Venkatesan
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-9529) Using injected JMS in a background task/thread leads to NameNotFoundException: java:comp/TransactionSynchronizationRegistry
by Scott Van Wart (JIRA)
[ https://issues.jboss.org/browse/WFLY-9529?page=com.atlassian.jira.plugin.... ]
Scott Van Wart commented on WFLY-9529:
--------------------------------------
Confirming issue is still present in Wildfly 13.0.0.Final:
{noformat}
11:11:54,213 WARN [TASK.SERVICE] (MSC service thread 1-5) Error creating/sending announcement: java.lang.RuntimeException: javax.naming.NameNotFoundException: java:comp/TransactionSynchronizationRegistry
at org.wildfly.extension.messaging.activemq.deployment.injection.InjectedJMSContext.lookup(InjectedJMSContext.java:145)
at org.wildfly.extension.messaging.activemq.deployment.injection.InjectedJMSContext.getTransactionSynchronizationRegistry(InjectedJMSContext.java:120)
at org.wildfly.extension.messaging.activemq.deployment.injection.InjectedJMSContext.isInTransaction(InjectedJMSContext.java:109)
at org.wildfly.extension.messaging.activemq.deployment.injection.InjectedJMSContext.getDelegate(InjectedJMSContext.java:87)
at org.wildfly.extension.messaging.activemq.deployment.injection.JMSContextWrapper.createObjectMessage(JMSContextWrapper.java:142)
at task.impl.TaskServiceImpl.lambda$announce$4(TaskServiceImpl.java:409)
at jms.JmsServiceImpl.withJmsContext(JmsServiceImpl.java:83)
at jms.JmsServiceImpl$Proxy$_$$_WeldSubclass.withJmsContext(Unknown Source)
at jms.JmsServiceImpl.withJmsContextInTransaction(JmsServiceImpl.java:92)
at jms.JmsServiceImpl$Proxy$_$$_WeldSubclass.withJmsContextInTransaction$$super(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.weld.interceptor.proxy.TerminalAroundInvokeInvocationContext.proceedInternal(TerminalAroundInvokeInvocationContext.java:51)
at org.jboss.weld.interceptor.proxy.AroundInvokeInvocationContext.proceed(AroundInvokeInvocationContext.java:78)
at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.invokeInOurTx(TransactionalInterceptorBase.java:174)
at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired.doIntercept(TransactionalInterceptorRequired.java:53)
at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.intercept(TransactionalInterceptorBase.java:88)
at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired.intercept(TransactionalInterceptorRequired.java:47)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:73)
at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeAroundInvoke(InterceptorMethodHandler.java:84)
at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:72)
at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:56)
at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:79)
at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:68)
at com.indosoft.qsuite.jms.JmsServiceImpl$Proxy$_$$_WeldSubclass.withJmsContextInTransaction(Unknown Source)
at com.indosoft.qsuite.jms.JmsServiceImpl$Proxy$_$$_WeldClientProxy.withJmsContextInTransaction(Unknown Source)
at com.indosoft.qsuite.task.impl.TaskServiceImpl.announce(TaskServiceImpl.java:405)
at com.indosoft.qsuite.task.impl.TaskServiceImpl.initialize(TaskServiceImpl.java:102)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:95)
at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:85)
at org.jboss.weld.injection.MethodInvocationStrategy$SimpleMethodInvocationStrategy.invoke(MethodInvocationStrategy.java:129)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:330)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:308)
at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:286)
at org.jboss.weld.util.Observers.notify(Observers.java:172)
at org.jboss.weld.event.ObserverNotifier.notifySyncObservers(ObserverNotifier.java:285)
at org.jboss.weld.event.ObserverNotifier.notify(ObserverNotifier.java:273)
at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:177)
at org.jboss.weld.bootstrap.BeanDeploymentModule.fireEvent(BeanDeploymentModule.java:93)
at org.jboss.weld.bootstrap.WeldStartup.endInitialization(WeldStartup.java:570)
at org.jboss.weld.bootstrap.WeldBootstrap.endInitialization(WeldBootstrap.java:100)
at org.jboss.as.weld.WeldStartCompletionService.start(WeldStartCompletionService.java:57)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1736)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1698)
at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
at java.lang.Thread.run(Thread.java:748)
Caused by: javax.naming.NameNotFoundException: java:comp/TransactionSynchronizationRegistry
at org.jboss.as.naming.InitialContext$DefaultInitialContext.findContext(InitialContext.java:191)
at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:235)
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
at org.wildfly.extension.messaging.activemq.deployment.injection.InjectedJMSContext.lookup(InjectedJMSContext.java:143)
... 59 more
{noformat}
> Using injected JMS in a background task/thread leads to NameNotFoundException: java:comp/TransactionSynchronizationRegistry
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9529
> URL: https://issues.jboss.org/browse/WFLY-9529
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, JMS, Naming
> Affects Versions: 10.1.0.Final, 11.0.0.Final, 12.0.0.Final, 13.0.0.Final
> Environment: Running on Windows 10, Java 64-bit 1.8.0_131
> Reporter: Scott Van Wart
> Assignee: Eduardo Martins
> Labels: ActiveMQ, jms, transaction
> Attachments: injected-jms.zip, injected-jms2.zip, wildfly-11-injected-jms.txt
>
>
> If I try to use an @Injected JMSContext while executing within a background task (ManagedExecutorService) or thread (ManagedThreadFactory), I get the attached stacktrace. I've experienced this a number of times with Wildfly 10.1.0, including messages sent in Infinispan's expiry task thread.
> My original workaround was to submit an additional task on a separate thread to send the message, then wait for it to complete. That seemed unreliable (sometimes it would still produce NameNotFoundException). I've resorted to creating my own JMSContext by using @Resource( lookup="java:/ConnectionFactory" ) and sending messages that way. Both workarounds prevent the message sending logic from participating in any ongoing transactions.
> I'm also attaching a sample EAR project. It can be built with Maven. It creates a background task that waits 3 seconds and then tries to send a JMS message in a new transaction using an injected JMS context. I use the standalone-full.xml profile to run it.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-9529) Using injected JMS in a background task/thread leads to NameNotFoundException: java:comp/TransactionSynchronizationRegistry
by Scott Van Wart (JIRA)
[ https://issues.jboss.org/browse/WFLY-9529?page=com.atlassian.jira.plugin.... ]
Scott Van Wart updated WFLY-9529:
---------------------------------
Affects Version/s: 13.0.0.Final
> Using injected JMS in a background task/thread leads to NameNotFoundException: java:comp/TransactionSynchronizationRegistry
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9529
> URL: https://issues.jboss.org/browse/WFLY-9529
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, JMS, Naming
> Affects Versions: 10.1.0.Final, 11.0.0.Final, 12.0.0.Final, 13.0.0.Final
> Environment: Running on Windows 10, Java 64-bit 1.8.0_131
> Reporter: Scott Van Wart
> Assignee: Eduardo Martins
> Labels: ActiveMQ, jms, transaction
> Attachments: injected-jms.zip, injected-jms2.zip, wildfly-11-injected-jms.txt
>
>
> If I try to use an @Injected JMSContext while executing within a background task (ManagedExecutorService) or thread (ManagedThreadFactory), I get the attached stacktrace. I've experienced this a number of times with Wildfly 10.1.0, including messages sent in Infinispan's expiry task thread.
> My original workaround was to submit an additional task on a separate thread to send the message, then wait for it to complete. That seemed unreliable (sometimes it would still produce NameNotFoundException). I've resorted to creating my own JMSContext by using @Resource( lookup="java:/ConnectionFactory" ) and sending messages that way. Both workarounds prevent the message sending logic from participating in any ongoing transactions.
> I'm also attaching a sample EAR project. It can be built with Maven. It creates a background task that waits 3 seconds and then tries to send a JMS message in a new transaction using an injected JMS context. I use the standalone-full.xml profile to run it.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-9529) Using injected JMS in a background task/thread leads to NameNotFoundException: java:comp/TransactionSynchronizationRegistry
by Scott Van Wart (JIRA)
[ https://issues.jboss.org/browse/WFLY-9529?page=com.atlassian.jira.plugin.... ]
Scott Van Wart updated WFLY-9529:
---------------------------------
Component/s: CDI / Weld
> Using injected JMS in a background task/thread leads to NameNotFoundException: java:comp/TransactionSynchronizationRegistry
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9529
> URL: https://issues.jboss.org/browse/WFLY-9529
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, JMS, Naming
> Affects Versions: 10.1.0.Final, 11.0.0.Final, 12.0.0.Final
> Environment: Running on Windows 10, Java 64-bit 1.8.0_131
> Reporter: Scott Van Wart
> Assignee: Eduardo Martins
> Labels: ActiveMQ, jms, transaction
> Attachments: injected-jms.zip, injected-jms2.zip, wildfly-11-injected-jms.txt
>
>
> If I try to use an @Injected JMSContext while executing within a background task (ManagedExecutorService) or thread (ManagedThreadFactory), I get the attached stacktrace. I've experienced this a number of times with Wildfly 10.1.0, including messages sent in Infinispan's expiry task thread.
> My original workaround was to submit an additional task on a separate thread to send the message, then wait for it to complete. That seemed unreliable (sometimes it would still produce NameNotFoundException). I've resorted to creating my own JMSContext by using @Resource( lookup="java:/ConnectionFactory" ) and sending messages that way. Both workarounds prevent the message sending logic from participating in any ongoing transactions.
> I'm also attaching a sample EAR project. It can be built with Maven. It creates a background task that waits 3 seconds and then tries to send a JMS message in a new transaction using an injected JMS context. I use the standalone-full.xml profile to run it.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-9529) Using injected JMS in a background task/thread leads to NameNotFoundException: java:comp/TransactionSynchronizationRegistry
by Scott Van Wart (JIRA)
[ https://issues.jboss.org/browse/WFLY-9529?page=com.atlassian.jira.plugin.... ]
Scott Van Wart commented on WFLY-9529:
--------------------------------------
I just had a javax.naming.NameNotFoundException: java:comp/TransactionSynchronizationRegistry with no immediate CDI events involved. [~emmartins] I'm speculating that an earlier CDI event lead to a pollution of a managed thread and that random chance lead this random thread to be used with a JMSContext that was injected:
# Service.initialize( @Observes @Initialized( ApplicationScoped.class ) Object event ) gets called
# Call ManagedExecutorService.submit( Runnable ) from that thread.
# That Runnable executes and eventually submits another Runnable to the same executor service.
# That Runnable is executed and itself submits a THIRD runnable to a completely separate executor service.
# When this third runnable is run, it hits its first @Transactional barrier, then tries to call JMSContext.createTextMessage which throws javax.naming.NameNotFoundException: java:comp/TransactionSynchronizationRegistry.
This is an actual workflow in our application. A connection thread created in (2) submits worker tasks (3) to process incoming events. The event discovers it needs to wait on something else and registers a callback. When that something else happens the callback is scheduled on the executor service (4).
What's immensely frustrating about this is things will run fine for several weeks or possibly a month or more. Then I'll get a report back and immediately notice "javax.naming.NameNotFoundException: java:comp/TransactionSynchronizationRegistry" and play a game of musical chairs with my uncomfortably obtuse list of workarounds until I find one that will keep things going awhile longer.
Workarounds I have:
* Create a connection manually from java:/ConnectionFactory and manage its state from start to finish. Any time I want it to participate in a distributed transaction I need to look up java:comp/TransactionSynchronizationRegistry myself and register a Synchronization. I can't take advantage of connection pooling and it really strains the idea that it's a fully distributed transaction and not a risky post-commit hack. I also can't use multithreading because a single JMS session created in this fashion can't be used by multiple threads (if I'm interested in using transactions, which I unquestionably am). In cases where I can't avoid multithreading, I'm queuing up the data I want to send within the transaction, and only using the session at the very end of the transaction to fire off its messages as quickly as possible. This kills performance. I could pool connections, but then I might as well write my own JMS<->container integration.
* Wrap all my JMSContext usage with a simple EJB. This absolutely kills performance on anything but the occasional message.
* Don't use @Observes @Initialized( ApplicationScoped.class ). That would eliminate only a small fraction of the CDI events we're using in our product.
> Using injected JMS in a background task/thread leads to NameNotFoundException: java:comp/TransactionSynchronizationRegistry
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9529
> URL: https://issues.jboss.org/browse/WFLY-9529
> Project: WildFly
> Issue Type: Bug
> Components: JMS, Naming
> Affects Versions: 10.1.0.Final, 11.0.0.Final, 12.0.0.Final
> Environment: Running on Windows 10, Java 64-bit 1.8.0_131
> Reporter: Scott Van Wart
> Assignee: Eduardo Martins
> Labels: ActiveMQ, jms, transaction
> Attachments: injected-jms.zip, injected-jms2.zip, wildfly-11-injected-jms.txt
>
>
> If I try to use an @Injected JMSContext while executing within a background task (ManagedExecutorService) or thread (ManagedThreadFactory), I get the attached stacktrace. I've experienced this a number of times with Wildfly 10.1.0, including messages sent in Infinispan's expiry task thread.
> My original workaround was to submit an additional task on a separate thread to send the message, then wait for it to complete. That seemed unreliable (sometimes it would still produce NameNotFoundException). I've resorted to creating my own JMSContext by using @Resource( lookup="java:/ConnectionFactory" ) and sending messages that way. Both workarounds prevent the message sending logic from participating in any ongoing transactions.
> I'm also attaching a sample EAR project. It can be built with Maven. It creates a background task that waits 3 seconds and then tries to send a JMS message in a new transaction using an injected JMS context. I use the standalone-full.xml profile to run it.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10577) Undertow subsystem should not depend on clustering code.
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-10577?page=com.atlassian.jira.plugin... ]
Paul Ferraro edited comment on WFLY-10577 at 6/15/18 9:46 AM:
--------------------------------------------------------------
{quote}I can understand the dependency to org.wildfly.clustering.service for web cache thingie.
However org.jboss.as.clustering.common does not deal about that. It is an abstraction on top of the Core API, right?{quote}
The wildfly-clustering-service module depends primarily on jboss-msc and jboss-modules, and does not depend on anything from wildfly-core ^1^. The fundamental abstraction is ServiceConfigurator, which encapsulates the logic for configuring a service, the goal of which is to eliminate code duplication for services built by multiple subsystems. This module contains interfaces/class originally extracted from wildfly-clustering-common, and is as a dependency of the public API for building singleton services (i.e. org.wildfly.clustering.singleton.api).
The wildfly-clustering-common module (at least the stuff we're talking about) depends primarily on wildfly-clustering-service *and* wildfly-controller (from wildfly-core). The bulk of this module deals with simplifying subsystem development. However, there are a couple of interfaces that are specific used by the clustering SPIs that relate to building/configuring services whose dependencies require capability resolution. These really ought to be split out, either into a separate module (without "clustering" in the name), or (preferably) pulled into wildfly-controller (within core).
\[1] https://github.com/wildfly/wildfly/blob/master/servlet-feature-pack/src/m...
{quote}My concern is having subsystem code depends on another one for core features.{quote}
wildfly-clustering-common isn't a subsystem. It's just logic that was originally common to the clustering subsystems.
{quote}That makes the whole codebase harder to maintain as we have different ways to do the same thing (dealing with MSC Service in that case).{quote}
I understand the concern. I'll propose a solution at the end of my comments.
{quote}If the Core API (or the MSC Service API) does not provide the correct abstraction (or need another level of abstraction), these features should be done in a place that benefits all subsystems.{quote}
I completely agree. I proposed migrating some of its core abstractions to wildfly-core a couple of years ago, but we never reached a consensus.
{quote}By the way, the dependency from wildfly-undertow to wildfly-clustering-common is not direct and goes through wildfly-security > wildfly-clustering-infinispan-spi
\[...]
That's why I was not sure if the dependency was intentional or just a byproduct of being available...
{quote}
On the contrary - it's a direct dependency of the SPIs involved in clustering integration with wildfly-clustering-web-undertow. e.g.
https://github.com/wildfly/wildfly/blob/master/undertow/src/main/java/org...
Here's what I would propose:
1. Extract the non-deprecated interfaces/classes for configuring services and registering dependencies from wildfly-clustering-service into a separate module, let's call it wildfly-service. Since this module has no dependencies on any module from wildfly or wildfly-core, this can either reside in a separate maven repo (a la wildfly-common) or within wildfly-core.
2. Extract the interfaces/classes from wildfly-clustering-common appropriate for inclusion into wildfly-controller (within wildfly-core), minimally:
* CapabilityServiceConfigurator (extends ServiceConfigurator adding ability to configure itself from an OperationContext, specifically to resolve names of dependencies provided by capabilities)
* ResourceServiceConfigurator (extends ServiceConfigurator adding ability to configure itself from an OperationContext and Resource model)
* ResourceServiceHandler (encapsulates logic for adding/removing services for a resource - this is logic that is normally duplicated between add/remove operation handlers)
* SimpleResourceServiceHandler (a ResourceServiceHandler that add/removes a single service using a ResourceServiceConfigurator)
* Skeleton add/remove/write-attribute OperationStepHandlers that leverage ResourceServiceHandler
* Binary/UnaryCapabilityNameResolver (common dynamic capability name mapper implementations - to be used in lieu of lambdas)
This would be sufficient to remove the undertow subsystem dependency on wildfly-clustering-common and wildfly-clustering-service. WDYT?
was (Author: pferraro):
{quote}I can understand the dependency to org.wildfly.clustering.service for web cache thingie.
However org.jboss.as.clustering.common does not deal about that. It is an abstraction on top of the Core API, right?{quote}
The wildfly-clustering-service module depends primarily on jboss-msc and jboss-modules, and does not depend on anything from wildfly-core ^1^. The fundamental abstraction is ServiceConfigurator, which encapsulates the logic for configuring a service, the goal of which is to eliminate code duplication for services built by multiple subsystems. This module contains interfaces/class originally extracted from wildfly-clustering-common, and is as a dependency of the public API for building singleton services (i.e. org.wildfly.clustering.singleton.api).
The wildfly-clustering-common module (at least the stuff we're talking about) depends primarily on wildfly-clustering-service *and* wildfly-controller (from wildfly-core). The bulk of this module deals with simplifying subsystem development. However, there are a couple of interfaces that are specific used by the clustering SPIs that relate to building/configuring services whose dependencies require capability resolution. These really ought to be split out, either into a separate module (without "clustering" in the name), or (preferably) pulled into wildfly-controller (within core).
\[1] https://github.com/wildfly/wildfly/blob/master/servlet-feature-pack/src/m...
{quote}My concern is having subsystem code depends on another one for core features.{quote}
wildfly-clustering-common isn't a subsystem. It's just logic that was originally common to the clustering subsystems.
{quote}That makes the whole codebase harder to maintain as we have different ways to do the same thing (dealing with MSC Service in that case).{quote}
I understand the concern. I'll propose a solution at the end of my comments.
{quote}If the Core API (or the MSC Service API) does not provide the correct abstraction (or need another level of abstraction), these features should be done in a place that benefits all subsystems.{quote}
I completely agree. I proposed migrating some of its core abstractions to wildfly-core a couple of years ago, but we never reached a consensus.
{quote}By the way, the dependency from wildfly-undertow to wildfly-clustering-common is not direct and goes through wildfly-security > wildfly-clustering-infinispan-spi
\[...]
That's why I was not sure if the dependency was intentional or just a byproduct of being available...
{quote}
On the contrary - it's a direct dependency of the SPIs involved in clustering integration with wildfly-clustering-web-undertow. e.g.
https://github.com/wildfly/wildfly/blob/master/undertow/src/main/java/org...
Here's what I would propose:
1. Extract the non-deprecated interfaces/classes for configuring services and registering dependencies from wildfly-clustering-service into a separate module, let's call it wildfly-service. Since this module has no dependencies on any module from wildfly or wildfly-core, this can either reside in a separate maven repo or within wildfly-core.
2. Extract the interfaces/classes from wildfly-clustering-common appropriate for inclusion into wildfly-controller (within wildfly-core), minimally:
* CapabilityServiceConfigurator (extends ServiceConfigurator adding ability to configure itself from an OperationContext, specifically to resolve names of dependencies provided by capabilities)
* ResourceServiceConfigurator (extends ServiceConfigurator adding ability to configure itself from an OperationContext and Resource model)
* ResourceServiceHandler (encapsulates logic for adding/removing services for a resource - this is logic that is normally duplicated between add/remove operation handlers)
* SimpleResourceServiceHandler (a ResourceServiceHandler that add/removes a single service using a ResourceServiceConfigurator)
* Skeleton add/remove/write-attribute OperationStepHandlers that leverage ResourceServiceHandler
* Binary/UnaryCapabilityNameResolver (common dynamic capability name mapper implementations - to be used in lieu of lambdas)
This would be sufficient to remove the undertow subsystem dependency on wildfly-clustering-common and wildfly-clustering-service. WDYT?
> Undertow subsystem should not depend on clustering code.
> --------------------------------------------------------
>
> Key: WFLY-10577
> URL: https://issues.jboss.org/browse/WFLY-10577
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Reporter: Jeff Mesnil
> Assignee: Paul Ferraro
>
> With WFLY-10352, Undertow subsystem now depends on Clustering code for Clustering's abstraction of the new MSC Service API. For example https://github.com/wildfly/wildfly/blob/master/undertow/src/main/java/org...
> As far as I can tell, the org.jboss.as.clustering.common module is bundled in servlet-feature-pack just so Undertow extension can access its API.
> This is not correct. Undertow should not have to depend on clustering for this kind of abstraction.
> Either these abstractions should be provided by Core or they should not be allowed.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFCORE-3932) Export configuration changes between two standalone instances
by ehsavoie Hugonnet (JIRA)
ehsavoie Hugonnet created WFCORE-3932:
-----------------------------------------
Summary: Export configuration changes between two standalone instances
Key: WFCORE-3932
URL: https://issues.jboss.org/browse/WFCORE-3932
Project: WildFly Core
Issue Type: Enhancement
Components: Management
Reporter: ehsavoie Hugonnet
Assignee: ehsavoie Hugonnet
Compute the configuration changes between 2 standalone instances and export them as a Galleon feature pack configuration.
This could be use to update or upgrade a Galleon provisioned instance that has been modified 'locally'
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month