[JBoss JIRA] (WFLY-2464) simpler (than OBJECT) parser for STRING parameters and properties
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2464?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-2464:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1026319
> simpler (than OBJECT) parser for STRING parameters and properties
> -----------------------------------------------------------------
>
> Key: WFLY-2464
> URL: https://issues.jboss.org/browse/WFLY-2464
> Project: WildFly
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: CLI
> Reporter: Alexey Loubyansky
> Assignee: Alexey Loubyansky
> Fix For: 8.0.0.CR1
>
>
> At the moment a general parser (which recognizes objects, lists, properties, etc) is used for properties and parameters of type STRING. The problem with this is that some characters that appear special in values of types OBJECT, PROPERTY, LIST, etc have to be escaped in values of type STRING. E.g.
> --connection-url=jdbc:h2:~/unifiedpush;DB_CLOSE_DELAY=-1
> Here the equals sign before -1 has to be escaped, otherwise the value will be treated as PROPERTY and the equals sign as a name/value separator.
--
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
11 years, 2 months
[JBoss JIRA] (WFLY-2427) Launcher API
by Rob Stryker (JIRA)
[ https://issues.jboss.org/browse/WFLY-2427?page=com.atlassian.jira.plugin.... ]
Rob Stryker reassigned WFLY-2427:
---------------------------------
Assignee: Rob Stryker
> 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
11 years, 2 months
[JBoss JIRA] (WFLY-2470) Incorrect namespace in jboss-as-cmp_1_1.xsd
by Darran Lofthouse (JIRA)
Darran Lofthouse created WFLY-2470:
--------------------------------------
Summary: Incorrect namespace in jboss-as-cmp_1_1.xsd
Key: WFLY-2470
URL: https://issues.jboss.org/browse/WFLY-2470
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: XML Frameworks
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 8.0.0.CR1
This file is currently showing: -
{code}
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:jboss:domain:cmp:1.0"
xmlns="urn:jboss:domain:cmp:1.0"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
version="1.0">
{code}
The tartet namespace should be 1.1
--
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
11 years, 2 months
[JBoss JIRA] (JGRP-1737) TP: ignore DONT_BUNDLE flag for sending of messages
by Bela Ban (JIRA)
Bela Ban created JGRP-1737:
------------------------------
Summary: TP: ignore DONT_BUNDLE flag for sending of messages
Key: JGRP-1737
URL: https://issues.jboss.org/browse/JGRP-1737
Project: JGroups
Issue Type: Enhancement
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.5
Currently, messages tagged with DONT_BUNDLE are sent separately, not as a message bundle through a bundler. On the receiver, they are passed up as single messages, ie. on a separate thread.
Sending a lot of single (possibly small) messages is inefficient; it would be better to bundle *all* message on the sender side. This requires a bundler which sends single messages immediately when no other messages are available to be sent.
SOLUTION (sender):
* If the bundler is *not* "old", ignore the DONT_BUNDLE flag and send the message through the bundler
* Else, same as now; send the message immediately as single message
SOLUTION (receiver):
* When reading the message list and creating the 4 batches (regular, oob, oob+internal, internal), if a message has DONT_BUNDLE set, pass it as single message to the corresponding thread pool and don't add it to the batch
This has the advantage that we have a more efficient way of sending messages (as message bundles), yet the behavior (and performance) at the receiver is the same as now
--
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
11 years, 2 months
[JBoss JIRA] (WFLY-880) jboss-cli.sh show deployment status is FAILED but application running well
by Alexey Loubyansky (JIRA)
[ https://issues.jboss.org/browse/WFLY-880?page=com.atlassian.jira.plugin.s... ]
Alexey Loubyansky updated WFLY-880:
-----------------------------------
Assignee: Brian Stansberry (was: Alexey Loubyansky)
> jboss-cli.sh show deployment status is FAILED but application running well
> --------------------------------------------------------------------------
>
> Key: WFLY-880
> URL: https://issues.jboss.org/browse/WFLY-880
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Environment: suse linux 11 sp2
> Reporter: jing chen
> Assignee: Brian Stansberry
> Labels: jboss
>
> run jboss-cli.sh to check the deployment status and it shows FAILED.
> NDO-2120:/opt/jboss/bin # /opt/jboss/bin/jboss-cli.sh --connect command="/deployment=nsm.ear:read-attribute(name=status)"
> {
> "outcome" => "success",
> "result" => "FAILED"
> }
> nsm.ear is our application. But our application runs well and can be login successfully using client and executing operations are succeed. please help what is problem. what should i do to check the problem.
--
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
11 years, 2 months
[JBoss JIRA] (WFLY-2469) Upgrade to HornetQ 2.4.0.CR1
by Jeff Mesnil (JIRA)
Jeff Mesnil created WFLY-2469:
---------------------------------
Summary: Upgrade to HornetQ 2.4.0.CR1
Key: WFLY-2469
URL: https://issues.jboss.org/browse/WFLY-2469
Project: WildFly
Issue Type: Component Upgrade
Security Level: Public (Everyone can see)
Components: JMS
Reporter: Jeff Mesnil
Assignee: Jeff Mesnil
Fix For: 8.0.0.CR1
HornetQ 2.4.0.CR1 depends on Netty 4.0.x versions that broke compatibility with Netty 3.x
--
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
11 years, 2 months
[JBoss JIRA] (WFLY-2454) Cannot stop recovery manager when configured with volatile store
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-2454?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on WFLY-2454:
-------------------------------------
Hi gui,
Please can you add the steps to reproduce this, including your customer properties file and where you are specifying your om.arjuna.ats.arjuna.common.propertiesFile property.
Many thanks,
Tom
> 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
11 years, 2 months
[JBoss JIRA] (WFLY-1893) Restarting server with a disabled DS enables the DS
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1893?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1893:
-----------------------------------------------
Stefano Maestri <smaestri(a)redhat.com> made a comment on [bug 952277|https://bugzilla.redhat.com/show_bug.cgi?id=952277]
Attention: Russel Dickenson
Release note text: enabled attribute is correctly marshaled on xml when :disable operation is used.
Let me know if you need something else.
> Restarting server with a disabled DS enables the DS
> ---------------------------------------------------
>
> Key: WFLY-1893
> URL: https://issues.jboss.org/browse/WFLY-1893
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JCA
> Reporter: Kabir Khan
> Assignee: Stefano Maestri
>
> See https://issues.jboss.org/browse/WFLY-1874
> If you add a datasource with
> subsystem=datasources/data-source=Test:add(jndi-name=java:/Test,jta=false,use-ccm=false,connection-url=url,driver-class=org.h2.Driver,driver-name=h2,user-name=user,password=pass,validate-on-match=false,background-validation=false,share-prepared-statements=false)
> it shows up as not enabled/undefined:
> {code}
> [standalone@localhost:9990 /] /subsystem=datasources/data-source=Test:read-resource{ "outcome" => "success",
> "result" => {
> ...
> "enabled" => false,
> {code}
> {code}
> [standalone@localhost:9990 /] /subsystem=datasources/data-source=Test:read-resource(include-defaults=false)
> {
> "outcome" => "success",
> "result" => {
> ... "enabled" => undefined,
> {code}
> This is persisted as
> {code}
> <datasource jta="false" jndi-name="java:/Test" pool-name="Test" enabled="false" use-ccm="false">
> <connection-url>url</connection-url>
> <driver-class>org.h2.Driver</driver-class>
> <driver>h2</driver>
> <security>
> <user-name>user</user-name>
> <password>pass</password>
> </security>
> <validation>
> <validate-on-match>false</validate-on-match>
> <background-validation>false</background-validation>
> </validation>
> <statement>
> <share-prepared-statements>false</share-prepared-statements>
> </statement>
> </datasource>
> {code}
> Now if you stop and start the server again you end up with enabled=true.
--
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
11 years, 2 months