[JBoss JIRA] (WFLY-2454) Cannot stop recovery manager when configured with volatile store
by gui borland (JIRA)
[ https://issues.jboss.org/browse/WFLY-2454?page=com.atlassian.jira.plugin.... ]
gui borland updated WFLY-2454:
------------------------------
Issue Type: Bug (was: Feature Request)
> Cannot stop recovery manager when configured with volatile store
> ----------------------------------------------------------------
>
> Key: WFLY-2454
> URL: https://issues.jboss.org/browse/WFLY-2454
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Transactions
> Affects Versions: 8.0.0.Beta1
> Reporter: gui borland
> Assignee: Tom Jenkinson
>
> When using jboss 5, i was able to configure a 'Volatile' action store. I understand it's not the most robust store, but in my case performance is more important than tx consistency.
> I tried to configure the Volatile store in AS 7.1.3 as well (using a custom jbossts-properties.xml file defined via the com.arjuna.ats.arjuna.common.propertiesFile systemsetting ), but doing that breaks the recovery thread. It prints out a warning message (Volatile storage does not support recovery blablabla...). That would be fine, but this recovery issue also prevents jboss from shutting down cleanly. I have to kill it to stop it.
--
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
12 years, 6 months
[JBoss JIRA] (WFLY-2455) Cannot configure the list of recovery modules due to ArjunaRecoveryManagerService hardcoding them
by gui borland (JIRA)
gui borland created WFLY-2455:
---------------------------------
Summary: Cannot configure the list of recovery modules due to ArjunaRecoveryManagerService hardcoding them
Key: WFLY-2455
URL: https://issues.jboss.org/browse/WFLY-2455
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Transactions
Affects Versions: 8.0.0.Beta1
Reporter: gui borland
Assignee: Tom Jenkinson
Using a custom jbossts-properties.xml file defined via the com.arjuna.ats.arjuna.common.propertiesFile systemsetting, i can register a custom recovery manager for arjuna.
However, the ArjunaRecoveryManagerService class overwrite the recovery configuration mentioned in my jbossts-properties.xml file with a hardcoded list of recovery modules.
This makes me wonder if/how the hornetq recovery (org.hornetq.jms.server.recovery.HornetQXAResourceRecover) gets registered in wildfly..
--
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
12 years, 6 months
[JBoss JIRA] (WFLY-2454) Cannot stop recovery manager when configured with volatile store
by gui borland (JIRA)
gui borland created WFLY-2454:
---------------------------------
Summary: Cannot stop recovery manager when configured with volatile store
Key: WFLY-2454
URL: https://issues.jboss.org/browse/WFLY-2454
Project: WildFly
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Transactions
Affects Versions: 8.0.0.Beta1
Reporter: gui borland
Assignee: Tom Jenkinson
When using jboss 5, i was able to configure a 'Volatile' action store. I understand it's not the most robust store, but in my case performance is more important than tx consistency.
I tried to configure the Volatile store in AS 7.1.3 as well (using a custom jbossts-properties.xml file defined via the com.arjuna.ats.arjuna.common.propertiesFile systemsetting ), but doing that breaks the recovery thread. It prints out a warning message (Volatile storage does not support recovery blablabla...). That would be fine, but this recovery issue also prevents jboss from shutting down cleanly. I have to kill it to stop it.
--
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
12 years, 6 months
[JBoss JIRA] (WFLY-2436) do not allow JPA deployment failure to stop the server
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-2436?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-2436:
------------------------------------
With fix applied, warnings will be logged but the server doesn't terminate:
{quote}
16:27:09,351 WARN [org.jboss.as.jpa] (Controller Boot Thread) JBAS011411: Unexpected problem gathering statistics: java.lang.IllegalStateException: JBAS011477: Persistence unit 'invaliddeploy.jar#TEST_PU' is not available
{quote}
> do not allow JPA deployment failure to stop the server
> ------------------------------------------------------
>
> Key: WFLY-2436
> URL: https://issues.jboss.org/browse/WFLY-2436
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JPA / Hibernate
> Reporter: Scott Marlow
> Assignee: Scott Marlow
> Fix For: 8.0.0.CR1
>
> Attachments: invaliddeploy.jar
>
>
> Deploying the attached invalid deployment, causes a deployment failure. Restarting the server with the attached deployment, can cause the server to terminate with:
> {quote}
> 14:03:24,361 ERROR [org.jboss.as.server] (Controller Boot Thread) JBAS015956: Caught exception during boot: java.lang.NullPointerException
> at org.jboss.as.jpa.management.EntityManagerFactoryLookup.entityManagerFactory(EntityManagerFactoryLookup.java:39)
> at org.jboss.as.jpa.hibernate4.management.HibernateEntityStatistics.getDynamicChildrenNames(HibernateEntityStatistics.java:145)
> at org.jboss.as.jpa.management.DynamicManagementStatisticsResource.getChildren(DynamicManagementStatisticsResource.java:166)
> at org.jboss.as.controller.registry.AbstractModelResource$DelegateResource.getChildren(AbstractModelResource.java:254) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:252) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:254) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:254) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:254) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:239) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:225) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.controller.registry.Resource$Tools.readModel(Resource.java:213) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.writeModel(ModelControllerImpl.java:567) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.controller.OperationContextImpl.createPersistenceResource(OperationContextImpl.java:223) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:512) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:274) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.finishStep(AbstractOperationContext.java:684) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:659) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:470) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:274) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:269) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:332) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:293) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.server.ServerService.boot(ServerService.java:356) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.server.ServerService.boot(ServerService.java:331) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:255) [wildfly-controller-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> {quote}
--
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
12 years, 6 months
[JBoss JIRA] (WFLY-2278) Deployer can't modify data source when datasources set as application resources
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2278?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2278:
-----------------------------------------------
Harald Pehl <hpehl(a)redhat.com> made a comment on [bug 1017786|https://bugzilla.redhat.com/show_bug.cgi?id=1017786]
The console uses @AccessControl annotations to bind 1-n resources to presenters. Presenters are the "P" in the MVP architecture used in the console. Most presenters are addressable using an URL like http://localhost:9990/console/App.html#datasources.
When the presenter is shown for the first time, the console reads the access control metadata of its configured resources to decide whether operations can be executed or attributes are readable/writable.
The datasource presenter is configured using the following resources:
@AccessControl(resources = {
"/{selected.profile}/subsystem=datasources/data-source=*",
"/{selected.profile}/subsystem=datasources/xa-data-source=*"
})
The current implementation uses an "all-or-nothing" rule: If not all resources are writable, none will be writable. To cut a long story short. Making also the xa-data-source an application resource will give the deployer the permissions to edit both the data-source and the xa-data-source resource:
/core-service=management/access=authorization/constraint=application-classification/type=datasources/classification=data-source:write-attribute(name=configured-application, value=true)
/core-service=management/access=authorization/constraint=application-classification/type=datasources/classification=xa-data-source:write-attribute(name=configured-application, value=true)
> Deployer can't modify data source when datasources set as application resources
> -------------------------------------------------------------------------------
>
> Key: WFLY-2278
> URL: https://issues.jboss.org/browse/WFLY-2278
> Project: WildFly
> Issue Type: Sub-task
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Ladislav Thon
> Assignee: Brian Stansberry
> Labels: rbac-filed-by-qa
> Fix For: 8.0.0.CR1
>
>
> When data sources are made application resources, deployer should be able to modify them. This doesn't work, as opposed to e.g. mail sessions. For example:
> {code}
> /core-service=management/access=authorization/constraint=application-classification/type=datasources/classification=data-source:write-attribute(name=configured-application, value=true)
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=datasources/data-source=ExampleDS:write-attribute(name=jndi-name, value="java:jboss/datasources/ExampleDS_XXX"){roles=deployer}
> {
> "outcome" => "failed",
> "failure-description" => "JBAS013456: Unauthorized to execute operation 'write-attribute' for resource '[
> (\"subsystem\" => \"datasources\"),
> (\"data-source\" => \"ExampleDS\")
> ]' -- \"JBAS013475: Permission denied\"",
> "rolled-back" => true
> }
> [standalone@localhost:9990 /] /core-service=management/access=authorization/constraint=application-classification/type=mail/classification=mail-session:write-attribute(name=configured-application, value=true)
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=mail/mail-session=java\:jboss\/mail\/Default:write-attribute(name=jndi-name, value="java:jboss/mail/Default_XXX"){roles=deployer}
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> {code}
> I have a test case for this as a last commit in my branch https://github.com/Ladicek/wildfly/commits/rbac (that is the commit called _RBAC test case for application types_).
> Brian, in case you are not the right assignee, please reassign.
--
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
12 years, 6 months
[JBoss JIRA] (JBCOMMON-131) Setting cache timeout for JAAS under jboss-eap-6.1 does not work
by Dimitris Andreadis (JIRA)
[ https://issues.jboss.org/browse/JBCOMMON-131?page=com.atlassian.jira.plug... ]
Dimitris Andreadis closed JBCOMMON-131.
---------------------------------------
Resolution: Rejected
First you hijack an old forum thread to ask a different question.
Then you pick up a random project tracker (JBCOMMON) and open a bug report for something that is not a bug but a usage question.
Learn how to ask questions properly:
https://community.jboss.org/wiki/HowToAskAForumQuestion
And ask your question in the AS7 user forum:
https://community.jboss.org/en/jbossas7
If you re-open the ticket, I'll just remove it.
PS
By just looking at your case you are probably referencing a cache that is not defined elsewhere.
> Setting cache timeout for JAAS under jboss-eap-6.1 does not work
> ----------------------------------------------------------------
>
> Key: JBCOMMON-131
> URL: https://issues.jboss.org/browse/JBCOMMON-131
> Project: JBoss Common
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Environment: jboss-eap-6.1
> Reporter: Artur Mioduszewski
> Assignee: Dimitris Andreadis
>
> When: cache-type="default" in security-domain configuration -> authentication works correctly.
> When I have used below configuration in order to try to set cache timeout in JAAS -> JAAS authentication stops to work - I am not able to log in (on JBoss console there are not any errors)
> <code>
> ...
> <security-domain name="myJaasDomain" cache-type="infinispan">
> <authentication>
> <login-module code="Database" flag="required">
> <module-option name="dsJndiName" value="java:jboss/datasources/digital-signal-service-dev-ws-DS"/>
> <module-option name="principalsQuery" value="SELECT l.PASSWORD FROM LOGIN l WHERE l.USERNAME=?"/>
> <module-option name="rolesQuery" value="SELECT ar.NAME, 'Roles' FROM login l, login_access_group lg, access_group g, access_group_s_access_right ga, s_access_right ar WHERE l.username = ? AND l.id = lg.login_ID AND lg.groups_ID = g.id AND g.ID = ga.access_group_ID AND ga.accessRights_ID = ar.ID"/>
> <module-option name="hashAlgorithm" value="MD5"/>
> <module-option name="hashEncoding" value="base64"/>
> <module-option name="unauthenticatedIdentity" value="guest"/>
> </login-module>
> </authentication>
> </security-domain>
> ...
> <subsystem xmlns="urn:jboss:domain:infinispan:1.2" default-cache-container="web">
> <cache-container name="cluster" aliases="ha-partition" default-cache="default">
> <transport lock-timeout="60000"/>
> <replicated-cache name="default" mode="SYNC" batching="true">
> <locking isolation="REPEATABLE_READ"/>
> </replicated-cache>
> </cache-container>
> <cache-container name="web" aliases="standard-session-cache" default-cache="repl">
> <transport lock-timeout="60000"/>
> <replicated-cache name="repl" mode="ASYNC" batching="true">
> <file-store/>
> </replicated-cache>
> <replicated-cache name="sso" mode="SYNC" batching="true"/>
> <distributed-cache name="dist" mode="ASYNC" batching="true">
> <file-store/>
> </distributed-cache>
> </cache-container>
> <cache-container name="ejb" aliases="sfsb sfsb-cache" default-cache="repl">
> <transport lock-timeout="60000"/>
> <replicated-cache name="repl" mode="ASYNC" batching="true">
> <file-store/>
> </replicated-cache>
> <replicated-cache name="remote-connector-client-mappings" mode="SYNC" batching="true"/>
> <distributed-cache name="dist" mode="ASYNC" batching="true">
> <file-store/>
> </distributed-cache>
> </cache-container>
> <cache-container name="hibernate" default-cache="local-query">
> <transport lock-timeout="60000"/>
> <local-cache name="local-query">
> <transaction mode="NONE"/>
> <expiration max-idle="100000"/>
> </local-cache>
> <invalidation-cache name="entity" mode="SYNC">
> <transaction mode="NON_XA"/>
> <expiration max-idle="100000"/>
> </invalidation-cache>
> <replicated-cache name="timestamps" mode="ASYNC">
> <transaction mode="NONE"/>
> </replicated-cache>
> </cache-container>
> </subsystem>
> ...
> <code>
--
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
12 years, 6 months
[JBoss JIRA] (WFLY-2453) Expose statistics configuration attribute per JGroups protocol
by Paul Ferraro (JIRA)
Paul Ferraro created WFLY-2453:
----------------------------------
Summary: Expose statistics configuration attribute per JGroups protocol
Key: WFLY-2453
URL: https://issues.jboss.org/browse/WFLY-2453
Project: WildFly
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Reporter: Paul Ferraro
By default, every JGroups protocol gathers statistics. Currently, this can be disabled per protocol via:
<property name="stats">false</property>
This is a bit cumbersome. Also, a standard property like this should be 1st class attribute of the <protocol/> element.
e.g..
<protocol type="..." statistics="false"/>
We may also want to add the ability to disable statistics per stack, so the user does not have to explicitly disable it in every protocol. That way, to enable statistics for a single protocol, one could use:
<stack name="udp" statistics="false"><!-- Disables collection of statistics for all protocols -->
<transport type="UDP" statistics="true"/><!-- Enables collection of statistics for just this protocol -->
...
</stack>
--
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
12 years, 6 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 updated WFLY-2427:
-------------------------------
Description:
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.
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.
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
was:
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.
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.
> 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
>
> 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.
> 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.
> 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
12 years, 6 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 updated WFLY-2427:
-------------------------------
Description:
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
was:
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.
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.
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
> 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
>
> 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
12 years, 6 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:
------------------------------------
What's the input for Eclipse API?
To what extent should this go - in terms of reflecting all those system props by which various subsystems and deps may be affected? Maybe the known issues workarounds could be adressed by the API.
Other thing: Should this be a separate project, aiming to be backward compatible with older WildFly's, or would it be simply tied to WildFly releases and guaranteed to work with just that version?
> 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
>
> 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.
> 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.
--
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
12 years, 6 months