[JBoss JIRA] (WFLY-6942) Add a forget operation to the transaction subsystem tooling
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/WFLY-6942?page=com.atlassian.jira.plugin.... ]
Michael Musgrove resolved WFLY-6942.
------------------------------------
Release Notes Text: The transactions tooling operation to remove heuristically completed XA resource participants from transaction logs previously (to this release) did not invoke the forget operation on the resource. This call is useful since it facilitates clean up. In this release the forget operation is called when removing such participants. However, by default the result of the forget call is ignored and even if it fails the log is still removed. To override this behaviour the administrator can set a system property called ignoreMBeanHeuristics to the value false. With this value set participants will not be removed from the log if the forget call is unsuccessful.
Fix Version/s: 11.0.0.Alpha1
Resolution: Done
This operaton is fixed in WFLY-7241 (Upgrade Narayana to 5.3.5.Final).
Only the docs/release notes update for how to trigger the forget operation is pending.
> Add a forget operation to the transaction subsystem tooling
> -----------------------------------------------------------
>
> Key: WFLY-6942
> URL: https://issues.jboss.org/browse/WFLY-6942
> Project: WildFly
> Issue Type: Feature Request
> Components: Transactions
> Affects Versions: 10.1.0.CR1
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Fix For: 11.0.0.Alpha1
>
>
> The CLI tooling provides two features for dealing with heuristic participants:
> * a recover command that will move it back into the prepared state if the admin thinks a second prepare attempt is likely to succeed;
> * a delete operation if the admin thinks it safe to do so;
> In the case of XA resources we also need a forget operation which will trigger the resource adaptor to clean up its end instead of relying on the admin to use tooling provided by the RA to clean up.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 7 months
[JBoss JIRA] (WFLY-7252) war bean not visible for injection
by Teresa Miyar (JIRA)
[ https://issues.jboss.org/browse/WFLY-7252?page=com.atlassian.jira.plugin.... ]
Teresa Miyar updated WFLY-7252:
-------------------------------
Description:
In an ear file 2 wars and one shared lib, warA provides implementation for shared lib, warB cannot see warA implementation even though our documentation on chapter 12 states:
Chapter 12. Packaging and dep...
• In an application deployed as an ear, the container searches every bean archive bundled with
or referenced by the ear, including bean archives bundled with or referenced by wars, EJB jars
and rars contained in the ear. The bean archives might be library jars, EJB jars or war WEB-
INF/classes directories.
Then we have this:
See also the "5.1. Modularity",
http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#selection:
"A bean packaged in a certain module is available for injection, lookup and EL resolution to classes and JSP/JSF pages packaged in some other module if and only if the bean class of the bean is required to be accessible to the other module by the class accessibility requirements of the module architecture."
"In the Java EE module architecture, a bean class is accessible in a module if and only if it is required to be accessible according to the class loading requirements defined by the Java EE platform specification."
But the JavaEE spec states it "may" have access... it did have access on EAP6, does not have access on EAP7.
was:
In an ear file 2 wars and one shared lib, warA provides implementation for shared lib, warB cannot see warA implementation even though our documentation on chapter 12 states:
Chapter 12. Packaging and dep...
• In an application deployed as an ear, the container searches every bean archive bundled with
or referenced by the ear, including bean archives bundled with or referenced by wars, EJB jars
and rars contained in the ear. The bean archives might be library jars, EJB jars or war WEB-
INF/classes directories.
> war bean not visible for injection
> ----------------------------------
>
> Key: WFLY-7252
> URL: https://issues.jboss.org/browse/WFLY-7252
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Reporter: Teresa Miyar
> Assignee: Stuart Douglas
> Priority: Critical
> Attachments: DemoProjects.zip
>
>
> In an ear file 2 wars and one shared lib, warA provides implementation for shared lib, warB cannot see warA implementation even though our documentation on chapter 12 states:
> Chapter 12. Packaging and dep...
> • In an application deployed as an ear, the container searches every bean archive bundled with
> or referenced by the ear, including bean archives bundled with or referenced by wars, EJB jars
> and rars contained in the ear. The bean archives might be library jars, EJB jars or war WEB-
> INF/classes directories.
> Then we have this:
> See also the "5.1. Modularity",
> http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#selection:
> "A bean packaged in a certain module is available for injection, lookup and EL resolution to classes and JSP/JSF pages packaged in some other module if and only if the bean class of the bean is required to be accessible to the other module by the class accessibility requirements of the module architecture."
> "In the Java EE module architecture, a bean class is accessible in a module if and only if it is required to be accessible according to the class loading requirements defined by the Java EE platform specification."
> But the JavaEE spec states it "may" have access... it did have access on EAP6, does not have access on EAP7.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 7 months
[JBoss JIRA] (WFCORE-1846) WFLYSRV0153 error after attempting to explode archived subdeployments of archived deployments
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1846?page=com.atlassian.jira.plugi... ]
ehsavoie Hugonnet moved JBEAP-6275 to WFCORE-1846:
--------------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-1846 (was: JBEAP-6275)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Domain Management
(was: Domain Management)
Affects Version/s: 3.0.0.Alpha9
(was: 7.1.0.DR5)
> WFLYSRV0153 error after attempting to explode archived subdeployments of archived deployments
> ---------------------------------------------------------------------------------------------
>
> Key: WFCORE-1846
> URL: https://issues.jboss.org/browse/WFCORE-1846
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.0.Alpha9
> Reporter: ehsavoie Hugonnet
> Assignee: ehsavoie Hugonnet
>
> In archived deployments with archived subdeployments, the {{explode}} operation with {{path}} parameter defined to point at archived subdeployment causes the removal of whole deployment from the content repository.
> This operation is illegal, but the server should produce formed warning message with operation failing gracefully instead of throwing stack trace in this case.
> server.log:
> {code}09:05:07,664 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 29) WFLYUT0022: Unregistered web context: /subdeployment-test-web
> 09:05:07,701 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 2) WFLYCLINF0003: Stopped client-mappings cache from ejb container
> 09:05:07,719 INFO [org.jboss.as.server.deployment] (MSC service thread 1-7) WFLYSRV0208: Stopped subdeployment (runtime-name: subdeployment-test-ejb.jar) in 65ms
> 09:05:07,719 INFO [org.jboss.as.server.deployment] (MSC service thread 1-6) WFLYSRV0208: Stopped subdeployment (runtime-name: subdeployment-test-web.war) in 66ms
> 09:05:07,722 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0028: Stopped deployment subdeployment-test.ear (runtime-name: subdeployment-test.ear) in 69ms
> 09:05:07,732 INFO [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0009: Undeployed "subdeployment-test.ear" (runtime-name: "subdeployment-test.ear")
> 09:05:07,754 INFO [org.jboss.as.repository] (management-handler-thread - 2) WFLYDR0002: Content removed from location /home/mjurc/testing/wildfly/testsuite/integration/basic/target/jbossas/standalone/data/content/13/5a0425d908539149b62eb99b63710c67b13466/content
> 09:05:07,762 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) WFLYSRV0027: Starting deployment of "subdeployment-test.ear" (runtime-name: "subdeployment-test.ear")
> [0m[31m09:05:07,763 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.deployment.unit."subdeployment-test.ear".STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit."subdeployment-test.ear".STRUCTURE: WFLYSRV0153: Failed to process phase STRUCTURE of deployment "subdeployment-test.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896)
> 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: WFLYSRV0160: Failed to mount deployment content
> at org.jboss.as.server.deployment.module.DeploymentRootMountProcessor.deploy(DeploymentRootMountProcessor.java:95)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
> ... 5 more
> Caused by: java.io.FileNotFoundException: /home/mjurc/testing/wildfly/testsuite/integration/basic/target/jbossas/standalone/data/managed-exploded/subdeployment-test.ear (No such file or directory)
> at java.io.FileInputStream.open0(Native Method)
> at java.io.FileInputStream.open(FileInputStream.java:195)
> at java.io.FileInputStream.<init>(FileInputStream.java:138)
> at org.jboss.vfs.spi.RootFileSystem.openInputStream(RootFileSystem.java:51)
> at org.jboss.vfs.VirtualFile.openStream(VirtualFile.java:318)
> at org.jboss.vfs.VFS.mountZipExpanded(VFS.java:533)
> at org.jboss.as.server.deployment.DeploymentMountProvider$Factory$ServerDeploymentRepositoryImpl.mountDeploymentContent(DeploymentMountProvider.java:108)
> at org.jboss.as.server.deployment.module.DeploymentRootMountProcessor.deploy(DeploymentRootMountProcessor.java:91)
> ... 6 more
> [0m[31m09:05:07,765 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) WFLYCTL0013: Operation ("deploy") failed - address: (("deployment" => "subdeployment-test.ear")) - failure description: {
> "WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"subdeployment-test.ear\".STRUCTURE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"subdeployment-test.ear\".STRUCTURE: WFLYSRV0153: Failed to process phase STRUCTURE of deployment \"subdeployment-test.ear\"
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYSRV0160: Failed to mount deployment content
> Caused by: java.io.FileNotFoundException: /home/mjurc/testing/wildfly/testsuite/integration/basic/target/jbossas/standalone/data/managed-exploded/subdeployment-test.ear (No such file or directory)"},
> "WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"subdeployment-test.ear\".STRUCTURE"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
> }
> 09:05:07,767 ERROR [org.jboss.as.server] (management-handler-thread - 3) WFLYSRV0021: Deploy of deployment "subdeployment-test.ear" was rolled back with the following failure message:
> {
> "WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"subdeployment-test.ear\".STRUCTURE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"subdeployment-test.ear\".STRUCTURE: WFLYSRV0153: Failed to process phase STRUCTURE of deployment \"subdeployment-test.ear\"
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYSRV0160: Failed to mount deployment content
> Caused by: java.io.FileNotFoundException: /home/mjurc/testing/wildfly/testsuite/integration/basic/target/jbossas/standalone/data/managed-exploded/subdeployment-test.ear (No such file or directory)"},
> "WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"subdeployment-test.ear\".STRUCTURE"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
> }
> 09:05:07,768 INFO [org.jboss.as.server.deployment] (MSC service thread 1-8) WFLYSRV0028: Stopped deployment subdeployment-test.ear (runtime-name: subdeployment-test.ear) in 1ms
> 09:05:07,770 INFO [org.jboss.as.controller] (management-handler-thread - 3) WFLYCTL0183: Service status report
> WFLYCTL0186: Services which failed to start: service jboss.deployment.unit."subdeployment-test.ear".STRUCTURE{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 7 months
[JBoss JIRA] (WFLY-7252) war bean not visible for injection
by Teresa Miyar (JIRA)
Teresa Miyar created WFLY-7252:
----------------------------------
Summary: war bean not visible for injection
Key: WFLY-7252
URL: https://issues.jboss.org/browse/WFLY-7252
Project: WildFly
Issue Type: Bug
Components: CDI / Weld
Affects Versions: 10.1.0.Final, 10.0.0.Final
Reporter: Teresa Miyar
Assignee: Stuart Douglas
Priority: Critical
Attachments: DemoProjects.zip
In an ear file 2 wars and one shared lib, warA provides implementation for shared lib, warB cannot see warA implementation even though our documentation on chapter 12 states:
Chapter 12. Packaging and dep...
• In an application deployed as an ear, the container searches every bean archive bundled with
or referenced by the ear, including bean archives bundled with or referenced by wars, EJB jars
and rars contained in the ear. The bean archives might be library jars, EJB jars or war WEB-
INF/classes directories.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 7 months
[JBoss JIRA] (WFLY-7229) WFLYCLWEBUT0001 for server-side invalidated sessions
by Michał Nowakowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-7229?page=com.atlassian.jira.plugin.... ]
Michał Nowakowski commented on WFLY-7229:
-----------------------------------------
> I'm not sure why you need to disable server-side invalidation.
It was coded because two standard mechanisms you mentioned were considered not sufficient. I'm not saying they didn't work - they did and still do, but we wished to free resources faster than they can. I didn't say that earlier, but there are actually +30 sessions per user to wipe (+30 apps we thought we needed coordinated logout for, to free resources).
Now, in WF 10.1 (and only there) it's logging errors. That's why I think I need to disable it and try to live without, until the problem is resolved. Thankfully, we don't need to kill the sessions instantly for this logout to take effect. It's only a matter of lingering resources. I'm still not sure, but we hopefully have enough RAM available.
> If the session is later accessed by another node, the thread initiated on the first node will still expire the session
If I understood you right - then this is quite possibly what I want to happen.
> Undeploy of the application will not kill threads started in this way, thus your application will leak its classloader
Not a concern for me, that code is never undeployed.
> WFLYCLWEBUT0001 for server-side invalidated sessions
> ----------------------------------------------------
>
> Key: WFLY-7229
> URL: https://issues.jboss.org/browse/WFLY-7229
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Affects Versions: 10.1.0.Final
> Environment: Happens whenever <distributable/> is used in web.xml, both in standalone and domain modes.
> Reporter: Michał Nowakowski
> Assignee: Paul Ferraro
> Attachments: stacktrace_01.txt, stacktrace_02.txt, stacktrace_03.txt, testPortlet.tar.gz
>
>
> Attached is a simple webapp (pardon the name) with a single servlet "/main", that does the following:
> - a session is assigned (or created, if none existed before)
> - its details are printed and the browser is told to refresh after 20 seconds
> - before the browser refreshes, the session is invalidated server-side by separate thread.
> Expected behaviour is, that WF should give the user a new session. That's indeed how it works in standalone mode and without <distributable/> in web.xml. But in domain mode, OR with <distributable/> added (and, possibly, full-ha profile chosen), I get errors:
> - The first stacktrace happens when the thread invalidates the session.
> - The second stacktrace happens, when the browser refreshes. The user sees "Error 500".
> - Then, after a minute or so, I get the last one. It then repeats periodically.
> We can't upgrade from 10.0 because of this - and we know we need an upgrade because of fixes in Infinispan.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 7 months
[JBoss JIRA] (JASSIST-261) Issue with javassist on jdk 9b112
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-261?page=com.atlassian.jira.plugi... ]
Shigeru Chiba commented on JASSIST-261:
---------------------------------------
I've committed 3.21.0-GA. Could you upload it to maven repo?
Then I'll work on 3.22.0-CR1 for Java 9.
> Issue with javassist on jdk 9b112
> ---------------------------------
>
> Key: JASSIST-261
> URL: https://issues.jboss.org/browse/JASSIST-261
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.20.0-GA
> Environment: Javassist with jdk 9b112
> Reporter: Hoang Chuong Tran
> Assignee: Shigeru Chiba
>
> I am migrating a project to java 9, which also uses javassist to generate runtime code.
> One test of mine fails on jdk 9b112 while it passes on jdk 8u77.
> {noformat}
> import static javassist.CtClass.voidType;
> import java.lang.reflect.Method;
> import java.lang.reflect.Modifier;
> import java.util.HashMap;
> import java.util.Map;
> import org.junit.Test;
> import javassist.ClassClassPath;
> import javassist.ClassPool;
> import javassist.CtClass;
> import javassist.CtField;
> import javassist.CtMethod;
> import javassist.CtNewMethod;
> public class MyTests {
> public static class MyObject {
> protected Object field;
> Object getField() {return field;}
> public void setField(Object field) {}
> }
> @Test
> public void test() throws InstantiationException, IllegalAccessException {
> Class<? extends MyObject> clazz = compile(MyObject.class);
> clazz.newInstance().setField(null);
> }
> /** Compile a transfer class */
> public static synchronized Class<? extends MyObject> compile(Class<?> targetClass) {
> // Determine class setters
> Map<String, Method> setters = extractSetters(targetClass);
> ClassPool classPool = ClassPool.getDefault();
> classPool.insertClassPath(new ClassClassPath(targetClass));
> try {
> // Compile a new transfer class on the fly
> CtClass baseClass = classPool.get(MyObject.class.getName());
> CtClass proxyClass = classPool.makeClass(targetClass.getName() + "_Modified", baseClass);
> for(Method originalSetter : setters.values()) {
> // Create a field to hold the attribute
> Class<?> fieldClass = originalSetter.getParameterTypes()[0];
> CtClass fieldType = classPool.get(fieldClass.getName());
> String fieldName = originalSetter.getName().substring(3);
> CtField field = new CtField(fieldType, fieldName, proxyClass);
> proxyClass.addField(field);
> // Create a setter method to set that field
> CtClass[] parameters = new CtClass[] { fieldType };
> String setterBody = "{ System.out.println(\"Hello World\"); }";
> CtMethod setter = CtNewMethod.make(voidType, originalSetter.getName(), parameters, new CtClass[0], setterBody, proxyClass);
> proxyClass.addMethod(setter);
> }
> Class<? extends MyObject> javaClass = proxyClass.toClass(targetClass.getClassLoader(), targetClass.getProtectionDomain());
> return javaClass;
> } catch(Exception e) {
> throw new RuntimeException("Failure during transfer compilation for " + targetClass, e);
> }
> }
> /** Extract setter methods from a class */
> public static Map<String, Method> extractSetters(Class<?> cls) {
> Map<String, Method> setters = new HashMap<String, Method>();
> for(Method method : cls.getMethods()) {
> // Lookup setter methods
> if(method.getName().startsWith("set")) {
> // Only public setters
> int modifiers = method.getModifiers();
> if(Modifier.isPublic(modifiers)) {
> Class<?>[] exceptions = method.getExceptionTypes();
> Class<?>[] parameters = method.getParameterTypes();
> Class<?> returnType = method.getReturnType();
> if(exceptions.length <= 0 && parameters.length == 1 && "void".equals(returnType.getName())) {
> setters.put(method.getName(), method);
> }
> }
> }
> }
> return setters;
> }
> }
> {noformat}
> On jdk 8u77, the {{compile()}} function returns with success and "Hello world" is printed to the console.
> On jdk 9b112, I got the following exception
> {noformat}
> java.lang.RuntimeException: Failure during transfer compilation for class MyTests$MyObject
> at MyTests.compile(MyTests.java:68)
> at MyTests.test(MyTests.java:29)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
> at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:670)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: javassist.NotFoundException: java.lang.Object
> at javassist.ClassPool.get(ClassPool.java:450)
> at MyTests.compile(MyTests.java:51)
> ... 24 more
> {noformat}
> I suspect that is due to the jigsaw integration into the jdk.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 7 months
[JBoss JIRA] (WFLY-7209) Operation to list installed Resource Adapters
by Guillermo González de Agüero (JIRA)
[ https://issues.jboss.org/browse/WFLY-7209?page=com.atlassian.jira.plugin.... ]
Guillermo González de Agüero commented on WFLY-7209:
----------------------------------------------------
You're right, I was confusing it. Thanks for your explanation. I've updated the issue to better explain my real use case (that I still see intereresting despite my mistake).
There's a command to list enabled JDBC drivers. Web Console benefits from that so you can select from a list instead of manually specifying the archive name (screenshot "1-jbdc.png").
In screenshot "2-ra.png" you can see that a handwritten archive has to be specified for resource adapter activation. An operation to list "candidate" archives (e.g: rar files or ears with a @Connector or ra.xml file) would enable HAL to achieve my proposal.
I hope I've explained it better this time.
> Operation to list installed Resource Adapters
> ---------------------------------------------
>
> Key: WFLY-7209
> URL: https://issues.jboss.org/browse/WFLY-7209
> Project: WildFly
> Issue Type: Feature Request
> Components: JCA
> Reporter: Guillermo González de Agüero
> Assignee: Stefano Maestri
> Fix For: 10.1.0.Final
>
> Attachments: 1-jdbc.png, 2-ra.png
>
>
> Currently there's no way to list all the deployed Resource Adapters (modules or deployed archives). I propose to add a new operation to list installed RAs and their configuration, similar to the one available for JDBC drivers (see attached screenshots). This would allow HAL to provide a wizard of available options when configuring them.
> The command would be something like: /subsystem=resource-adapters:installed-resource-adapters-list()
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 7 months