[JBoss JIRA] (WFLY-2427) Launcher API
by Ondrej Zizka (JIRA)
[ https://issues.jboss.org/browse/WFLY-2427?page=com.atlassian.jira.plugin.... ]
Ondrej Zizka edited comment on WFLY-2427 at 12/4/13 10:48 AM:
--------------------------------------------------------------
As I was working on this, it seems that the most progressed in this field is Arquillian.
So I suggest:
What if we took Arquillian's Managed Wildfly container code and moved to a separate maven module.
This would need to decouple Arq's interfaces and types like exceptions and configs, not sure if possible since Arq needs these to extend it's base classes, but worth considering IMO.
Even if we don't do that, what I would create would be inspired by and could be used by Arquillian.
was (Author: ozizka):
As I was working on this, it seems that the most progressed in this field is Arquillian.
So I suggest:
What if we took Arquillian's Managed Wildfly container code and moved to a separate maven module.
This would need to decouple Arq's interfaces and types like exceptions and configs, not sure if possible since Arq needs these to extend it's base classes, but worth considering IMO.
> Launcher API
> ------------
>
> Key: WFLY-2427
> URL: https://issues.jboss.org/browse/WFLY-2427
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Server
> Reporter: Brian Stansberry
> Assignee: Rob Stryker
>
> 1) The AS should have some sort of API for launching our processes so tools that want a process have a clear contract instead of having to guess at what's relevant in our ever-changing scripts.
> 2) We want the main class in our process launch to be what's invoked by java -jar jboss-modules.jar. We don't want java -jar jboss-as-launcher.jar which does some stuff and then calls org.jboss.modules.Main.
> 3) JBoss Modules itself shouldn't have a lot of the stuff in it that's relevant to an AS launcher API, because many of those things are not relevant to JBoss Modules in a generic sense.
> What we could do though is provide a launcher lib that isn't involved at all in our normal boot. Something that would only be used by tools that want to launch a separate, i.e. non-embedded, AS process.
> So, some sort of stable configuration API and then a simple
> java.lang.Process launch()
> Basically, a utility that does the ProcessBuilder stuff that everybody is doing themselves now.
> h2. HOWEVER...
> Eclipse-based tools like JBDS use Eclipse APIs for launch and would not use the above launch() method.
> So, besides that launch method, look into adding some methods to give the necessary inputs to the Eclipse API be useful. So Eclipse-based tools don't ask it for the process but can still get a standard launch configuration.
> I'd only want to do that if those methods would return something generally understandable, but a String or List<String> for classpath, List<String>s for vm/program args, some representation that "-jar jboss-modules.jar" is the way to get the main class -- those all seem generic enough.
> Any "which VM" stuff is consider out of scope; choosing the VM is the responsibility of the tool. Options that are not universally supported across VMs and are those a function of VM choice, like whether to use -server, are also out of scope.
> h2. Example of EAP 6.0 launch:
> VM arguments:
> -server -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true "-Dorg.jboss.boot.log.file=/Users/max/products/runtimes/jboss-eap-6.0/standalone/log/boot.log" "-Dlogging.configuration=file:/Users/max/products/runtimes/jboss-eap-6.0/standalone/configuration/logging.properties" "-Djboss.home.dir=/Users/max/products/runtimes/jboss-eap-6.0"
> Program argument:
> -mp "/Users/max/products/runtimes/jboss-eap-6.0/modules" -jaxpmodule javax.xml.jaxp-provider org.jboss.as.standalone -b localhost --server-config=standalone.xml
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 7 months
[JBoss JIRA] (WFLY-2427) Launcher API
by Ondrej Zizka (JIRA)
[ https://issues.jboss.org/browse/WFLY-2427?page=com.atlassian.jira.plugin.... ]
Ondrej Zizka commented on WFLY-2427:
------------------------------------
As I was working on this, it seems that the most progressed in this field is Arquillian.
So I suggest:
What if we took Arquillian's Managed Wildfly container code and moved to a separate maven module.
This would need to decouple Arq's interfaces and types like exceptions and configs, not sure if possible since Arq needs these to extend it's base classes, but worth considering IMO.
> Launcher API
> ------------
>
> Key: WFLY-2427
> URL: https://issues.jboss.org/browse/WFLY-2427
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Server
> Reporter: Brian Stansberry
> Assignee: Rob Stryker
>
> 1) The AS should have some sort of API for launching our processes so tools that want a process have a clear contract instead of having to guess at what's relevant in our ever-changing scripts.
> 2) We want the main class in our process launch to be what's invoked by java -jar jboss-modules.jar. We don't want java -jar jboss-as-launcher.jar which does some stuff and then calls org.jboss.modules.Main.
> 3) JBoss Modules itself shouldn't have a lot of the stuff in it that's relevant to an AS launcher API, because many of those things are not relevant to JBoss Modules in a generic sense.
> What we could do though is provide a launcher lib that isn't involved at all in our normal boot. Something that would only be used by tools that want to launch a separate, i.e. non-embedded, AS process.
> So, some sort of stable configuration API and then a simple
> java.lang.Process launch()
> Basically, a utility that does the ProcessBuilder stuff that everybody is doing themselves now.
> h2. HOWEVER...
> Eclipse-based tools like JBDS use Eclipse APIs for launch and would not use the above launch() method.
> So, besides that launch method, look into adding some methods to give the necessary inputs to the Eclipse API be useful. So Eclipse-based tools don't ask it for the process but can still get a standard launch configuration.
> I'd only want to do that if those methods would return something generally understandable, but a String or List<String> for classpath, List<String>s for vm/program args, some representation that "-jar jboss-modules.jar" is the way to get the main class -- those all seem generic enough.
> Any "which VM" stuff is consider out of scope; choosing the VM is the responsibility of the tool. Options that are not universally supported across VMs and are those a function of VM choice, like whether to use -server, are also out of scope.
> h2. Example of EAP 6.0 launch:
> VM arguments:
> -server -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true "-Dorg.jboss.boot.log.file=/Users/max/products/runtimes/jboss-eap-6.0/standalone/log/boot.log" "-Dlogging.configuration=file:/Users/max/products/runtimes/jboss-eap-6.0/standalone/configuration/logging.properties" "-Djboss.home.dir=/Users/max/products/runtimes/jboss-eap-6.0"
> Program argument:
> -mp "/Users/max/products/runtimes/jboss-eap-6.0/modules" -jaxpmodule javax.xml.jaxp-provider org.jboss.as.standalone -b localhost --server-config=standalone.xml
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 7 months
[JBoss JIRA] (SECURITY-759) JASPIServerAuthenticationManager.isValid method should log configuration problems at WARN or ERROR level
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/SECURITY-759?page=com.atlassian.jira.plug... ]
RH Bugzilla Integration commented on SECURITY-759:
--------------------------------------------------
Paul Gier <pgier(a)redhat.com> changed the Status of [bug 901074|https://bugzilla.redhat.com/show_bug.cgi?id=901074] from MODIFIED to ON_QA
> JASPIServerAuthenticationManager.isValid method should log configuration problems at WARN or ERROR level
> --------------------------------------------------------------------------------------------------------
>
> Key: SECURITY-759
> URL: https://issues.jboss.org/browse/SECURITY-759
> Project: PicketBox
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: JBossSX
> Affects Versions: PicketBox_4_0_20.Beta1
> Reporter: Stefan Guilhen
> Assignee: Stefan Guilhen
> Fix For: 2.0.3.Beta2
>
>
> As reported by Josef Cacek:
> All fatal exception are swallowed in JASPIServerAuthenticationManager.isValid() method.
> {code}
> // PicketBox 4.0.9 used in EAP 6.0.0 - TRACE level
> catch(AuthException ae)
> {
> if(trace)
> log.trace("AuthException:",ae);
> }
> // PicketBox 4.0.14 - DEBUG level
> catch(AuthException ae)
> {
> PicketBoxLogger.LOGGER.debugIgnoredException(ae);
> }
> {code}
> It includes configuration errors, which should absolutely be visible on ERROR log level or another relevant level.
> We need to make sure to use ERROR log if the user-defined module cannot be found for instance.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 7 months
[JBoss JIRA] (SECURITY-751) Misleading stacktrace on server startup with malformed security-domain
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/SECURITY-751?page=com.atlassian.jira.plug... ]
RH Bugzilla Integration commented on SECURITY-751:
--------------------------------------------------
Paul Gier <pgier(a)redhat.com> changed the Status of [bug 979117|https://bugzilla.redhat.com/show_bug.cgi?id=979117] from MODIFIED to ON_QA
> Misleading stacktrace on server startup with malformed security-domain
> ----------------------------------------------------------------------
>
> Key: SECURITY-751
> URL: https://issues.jboss.org/browse/SECURITY-751
> Project: PicketBox
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: PicketBox
> Reporter: Stefan Guilhen
> Assignee: Stefan Guilhen
> Fix For: PicketBox_4_0_19.Final
>
>
> Description of problem:
> Misleading stack trace upon server startup. Occurs when adding a <security-domain> with a malformed <jsse> element.
> Version-Release number of selected component (if applicable):
> Picketbox version: 4.0.17.Final-redhat-1
> How reproducible:
> Always
> Steps to Reproduce:
> 1. Start the server in standalone mode.
> ./standalone.sh
> 2. Run the following jboss-cli.sh commands:
> /subsystem=security/security-domain=test:add()
> /subsystem=security/security-domain=test1/jsse=classic:add(keystore={password=123456})
> :reload
> 3. See the stacktrace:
> 11:49:45,138 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.security.security-domain.test: org.jboss.msc.service.StartException in service jboss.security.security-domain.test: JBAS013308: Unable to start the SecurityDomainService service
> at org.jboss.as.security.service.SecurityDomainService.start(SecurityDomainService.java:107)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: java.lang.RuntimeException: PBOX000117: Invalid KeyStore type: JKS
> at org.jboss.security.JBossJSSESecurityDomain.loadKeyAndTrustStore(JBossJSSESecurityDomain.java:469)
> at org.jboss.security.JBossJSSESecurityDomain.reloadKeyAndTrustStore(JBossJSSESecurityDomain.java:335)
> at org.jboss.as.security.service.SecurityDomainService.start(SecurityDomainService.java:104)
> ... 5 more
> Actual results:
> Stacktrace says that the keystore type "JKS" is not supported. This is the default keystore type, so this is not true.
> Expected results:
> I believe that the stacktrace should report that the keystore-url attribute is missing, since adding only that attribute causes the stacktrace to disappear.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 7 months