[JBoss JIRA] (WFLY-985) jboss-dmr APIs are unable to parse swedish characters
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-985?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on WFLY-985:
----------------------------------------------
Jay SenSharma <jsenshar(a)redhat.com> changed the Status of [bug 950164|https://bugzilla.redhat.com/show_bug.cgi?id=950164] from NEW to CLOSED
> jboss-dmr APIs are unable to parse swedish characters
> -----------------------------------------------------
>
> Key: WFLY-985
> URL: https://issues.jboss.org/browse/WFLY-985
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CLI
> Environment: All
> Reporter: Jay Kumar SenSharma
> Assignee: Alexey Loubyansky
> Labels: cli, dmr
> Fix For: 8.0.0.Alpha2
>
>
> JBossAS 7.2 dmr-api's are unable to parse swedish characters .
> Example:
> ========= Run the following CLI command which will fail:
> [standalone@localhost:9999 /] /core-service=management/ldap-connection=ldap_connection/:add(search-credential=jboss@123,url=ldap://xx.xx.xxx.xx:389,search-dn="ou=\\u00E5\\u00E5\\u00E5,dc=example,dc=com")
> Ideally it should have generated the following configuration inside the server profile (standalone.xml)
> <outbound-connections>
> <ldap name="ldap_connection" url="ldap://xx.xx.xxx.xx:389" search-dn="ou=ååå,dc=example,dc=com" search-credential="jboss@123"/>
> </outbound-connections>
--
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, 10 months
[JBoss JIRA] (WFLY-2376) DataSource properties are not persisting via CLI
by Jay Kumar SenSharma (JIRA)
[ https://issues.jboss.org/browse/WFLY-2376?page=com.atlassian.jira.plugin.... ]
Jay Kumar SenSharma reopened WFLY-2376:
---------------------------------------
The Pull request [1] does not seems to be fixing the issue.
With the above pull request build still we see that if the class_name is not provided for stale_connection, reauth_plugin and exception_sorter ....Still WildFly creates the DataSource Silently without throwing any error / exception.
The DataSource configuration mentioned inside the "standalone.xml" still has missing exception-sorter-properties, reauth-plugin-properties etc.
Ideally WildFly should have thrown some Error or notified the user that the configuration provided is incorrect hence the datasource can not be processed.
> DataSource properties are not persisting via CLI
> ------------------------------------------------
>
> Key: WFLY-2376
> URL: https://issues.jboss.org/browse/WFLY-2376
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JCA
> Affects Versions: 8.0.0.Beta1
> Reporter: Jay Kumar SenSharma
> Assignee: Stefano Maestri
>
> - The CLI command show that there are some valid configuration properties available like following while configuring DataSources, However those properties never get persisted in the DataSource configuration:
> {quote}
> ./jboss-cli.sh --user=admin --password=admin@123 -c --controller=remote://localhost:9999 command="/subsystem=datasources/data-source=testpool:read-resource-description(recursive=true)"
> "stale-connection-checker-properties" => {
> "type" => OBJECT,
> "description" => "The stale connection checker properties",
> "expressions-allowed" => true,
> "nillable" => true,
> "value-type" => STRING,
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "no-services"
> },
> "reauth-plugin-properties" => {
> "type" => OBJECT,
> "description" => "The properties for the reauthentication plugin",
> "expressions-allowed" => true,
> "nillable" => true,
> "value-type" => STRING,
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "no-services"
> },
> "exception-sorter-properties" => {
> "type" => OBJECT,
> "description" => "The exception sorter properties",
> "expressions-allowed" => true,
> "nillable" => true,
> "value-type" => STRING,
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "no-services"
> },
> {quote}
> - Following command never complains about any issue and the following command executed without any issue but the above properties are not persisted in the DataSource.
> ./jboss-cli.sh --user=admin --password=admin@123 -c --controller=remote://localhost:9999 command="/subsystem=datasources/data-source=testpool:add(jndi-name=\"java:jboss/TestDS\",driver-name=\"ojdbc6.jar\",connection-url=\"jdbc:oracle:thin:@DBHostName:1521:DBName\",user-name=\"user\",password=\"pass\",new-connection-sql=\"select 1 from dual\", check-valid-connection-sql=\"select 2 from dual\",valid-connection-checker-class-name=\"org.jboss.resource.adapter.jdbc.vendor.OracleValidConnectionChecker\",exception-sorter-properties={\"prop1\"=>\"value1\"},reauth-plugin-properties={\"reauthProp1\"=>\"reauthValue1\"},exception-sorter-properties={\"exceptionSorterProp1\"=>\"exceptionSorterValue1\"})"
> - The Generated DataSource looks like following:
> ${quote}
> <datasource jndi-name="java:jboss/TestDS" pool-name="testpool" enabled="true">
> <connection-url>jdbc:oracle:thin:@DBHostName:1521:DBName</connection-url>
> <driver>ojdbc6.jar</driver>
> <new-connection-sql>select 1 from dual</new-connection-sql>
> <security>
> <user-name>user</user-name>
> <password>pass</password>
> </security>
> <validation>
> <valid-connection-checker class-name="org.jboss.resource.adapter.jdbc.vendor.OracleValidConnectionChecker"/>
> <check-valid-connection-sql>select 2 from dual</check-valid-connection-sql>
> </validation>
> </datasource>
> ${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
10 years, 10 months
[JBoss JIRA] (WFLY-3112) One can't change history and decay with DynamicLoadBalanceFactorProvider
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3112?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3112:
-----------------------------------------------
Paul Gier <pgier(a)redhat.com> changed the Status of [bug 1075215|https://bugzilla.redhat.com/show_bug.cgi?id=1075215] from MODIFIED to ON_QA
> One can't change history and decay with DynamicLoadBalanceFactorProvider
> ------------------------------------------------------------------------
>
> Key: WFLY-3112
> URL: https://issues.jboss.org/browse/WFLY-3112
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.0.0.Final
> Reporter: Michal Babacek
> Assignee: Radoslav Husar
> Priority: Critical
> Fix For: 8.0.1.Final
>
> Attachments: redacted_log
>
>
> I'm under an ugly impression that one can't actually change {{history}} and {{decay}} attributes of *DynamicLoadBalanceFactorProvider*.
> I was trying to figure out why the new test suite of CustomLoadMetric tests does not pass. In order to get load figures without history and decay manipulation, I set the following:
> {code}
> <subsystem xmlns="urn:jboss:domain:modcluster:1.2">
> <mod-cluster-config advertise-socket="modcluster" connector="ajp">
> <dynamic-load-provider history="0">
> <custom-load-metric class="biz.karms.modcluster.CustomLoadMetric" weight="1">
> <property name="capacity" value="1000"/>
> <property name="loadfile" value="/tmp/mod_cluster-eapx/loadfileA"/>
> <property name="parseexpression" value="^LOAD: ([0-9]*)$"/>
> </custom-load-metric>
> </dynamic-load-provider>
> </mod-cluster-config>
> </subsystem>
> {code}
> The aforementioned {{history=0}} effectively means that there is just 1 "slot" for a one historical value on which decay function should work.
> If you take a look at the code in [DynamicLoadBalanceFactorProvider|https://github.com/modcluster/mod_cluste...] constructor, it is apparent
> that the size of the List that later serves for storing the historical values is set sooner than the actual [setHistory(int history)|https://github.com/modcluster/mod_cluster/blob/master/core/src/m...] method is called.
> The actual size of that List collection wouldn't do any harm by itself but it is being used in the aforementioned class with {{.size()}} to control cycles.
> The same IMHO holds for the decay attribute.
> Anyhow, I put some additional logging to the [DynamicLoadBalanceFactorProvider.java|https://github.com/modcluster/mod_c...]:
> {code}
> // Historical value contribute an exponentially decayed factor
> for (int i = 0; i < queue.size(); ++i) {
> double decay = 1 / Math.pow(decayFactor, i);
> totalDecay += decay;
> this.log.info("KTAG: totalLoad:"+totalLoad+", with decay:"+(totalLoad+queue.get(i).doubleValue() * decay));
> totalLoad += queue.get(i).doubleValue() * decay;
> }
> {code}
> and
> {code}
> try {
> // Normalize load with respect to capacity
> this.recordLoad(metricLoadHistory, metric.getLoad(engine) / metric.getCapacity());
> this.log.info("KTAG metricLoadHistory:"+metricLoadHistory.toString());
> totalWeight += weight;
> totalWeightedLoad += this.average(metricLoadHistory) * weight;
> } catch (Exception e) {
> this.log.error(e.getLocalizedMessage(), e);
> }
> {code}
> with the following being the output: [^redacted_log].
> So, despite having {{history=0}}, which should force the system to keep just 1, the current value, {{metricLoadHistory}} grew from
> {noformat}
> KTAG metricLoadHistory:[0.8]
> {noformat}
> to
> {noformat}
> KTAG metricLoadHistory:[0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.9, 0.8]
> {noformat}
> which is exactly [9|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/jav...] + [1|https://github.com/modcluster/mod_cluster/blob/master/core/src/main/jav...] in size :-)
> WDYT?
--
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, 10 months
[JBoss JIRA] (WFLY-1547) deploy directories not cleaned up
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1547?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1547:
-----------------------------------------------
Paul Gier <pgier(a)redhat.com> changed the Status of [bug 901210|https://bugzilla.redhat.com/show_bug.cgi?id=901210] from MODIFIED to ON_QA
> deploy directories not cleaned up
> ---------------------------------
>
> Key: WFLY-1547
> URL: https://issues.jboss.org/browse/WFLY-1547
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 8.0.0.Alpha1
> Reporter: Shaun Appleton
> Assignee: jaikiran pai
> Fix For: 8.0.0.Beta1
>
> Attachments: deployment_with_hack_no_hook.txt
>
>
> JBoss EAP 6.0.0 (and 6.0.1.ER3) doesn't clean up it's tmp/vfs directories.
> The following reproduces this -
> i) ensure run.conf has the -Xrs set
> ii) ensure deployments has a deployable .ear in it
> iii) ./run standalone.sh and allow the deployments to deploy
> iv) stop the EAP process ie kill <process_id>
> v) observe content tmp/vfs
> (The -Xrs parameter is used to "-Xrs" to prevent possible interference when JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP)
> This will eventually cause problems with lack of disk space.
> Note if the -Xrs parameter content is removed but the tmp/vfs dirs stills exist. This could potentially cause inode problems.
> It would be better if there were any additional code so the temp dirs are cleaned up on start up. That would resolve both the -Xrs problem and the excessive dir creation.
--
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, 10 months
[JBoss JIRA] (WFLY-2655) Show warning for JDBC drivers as modules with no driver
by Jeff Zhang (JIRA)
[ https://issues.jboss.org/browse/WFLY-2655?page=com.atlassian.jira.plugin.... ]
Jeff Zhang resolved WFLY-2655.
------------------------------
Fix Version/s: 8.0.1.Final
Resolution: Done
> Show warning for JDBC drivers as modules with no driver
> -------------------------------------------------------
>
> Key: WFLY-2655
> URL: https://issues.jboss.org/browse/WFLY-2655
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: JCA
> Affects Versions: 8.0.0.Beta1
> Reporter: James Livingston
> Assignee: Jeff Zhang
> Fix For: 8.0.1.Final
>
>
> If a <driver> if configured with no <driver-class>, it will attempt to locate the driver(s) via the service loader which should find all JDBC4-compliant drivers.
> When you install a non JDBC4-complicant driver as a module and no <driver-class>, the driver will not be installed. That is expected but emitting a warning that no-drivers could be found in the module would be useful to help users troubleshoot 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
10 years, 10 months
[JBoss JIRA] (WFLY-2897) Including Mojarra implementation in WAR file causes `com.sun.faces.config.ConfigurationException`
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/WFLY-2897?page=com.atlassian.jira.plugin.... ]
Farah Juma commented on WFLY-2897:
----------------------------------
I've created this post in the JSF forum to help anyone else who happens to come across this issue:
https://community.jboss.org/thread/238150
> Including Mojarra implementation in WAR file causes `com.sun.faces.config.ConfigurationException`
> -------------------------------------------------------------------------------------------------
>
> Key: WFLY-2897
> URL: https://issues.jboss.org/browse/WFLY-2897
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: JSF
> Affects Versions: 8.0.0.CR1
> Reporter: Lincoln Baxter III
> Assignee: Farah Juma
> Attachments: sample.zip
>
>
> This stack trace was taken from EAP6 or JBoss AS7 - but it also occurs on Wildfly.
> If possible, a nicer exception message (warning the user that they have included an implementation of JSF when,) might be useful. But I don't know the exact dynamics behind this interaction, so not sure what is possible here, or what "should" be the right interaction.
> I just know this was a bit hard to track down until randomly tripping on this in the POM and removing it.
> {code}
> 15:15:37,992 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 71) Critical error during deployment: : com.sun.faces.config.ConfigurationException: The tag named passThroughAttribute from namespace http://xmlns.jcp.org/jsf/core has a null handler-class defined
> at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.processHandlerClass(FaceletTaglibConfigProcessor.java:415) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.processTags(FaceletTaglibConfigProcessor.java:371) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.processTagLibrary(FaceletTaglibConfigProcessor.java:314) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> at com.sun.faces.config.processor.FaceletTaglibConfigProcessor.process(FaceletTaglibConfigProcessor.java:263) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:363) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:216) [jsf-impl-2.1.19-redhat-2.jar:2.1.19-redhat-2]
> at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:3339) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> at org.apache.catalina.core.StandardContext.start(StandardContext.java:3777) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> at org.jboss.as.web.deployment.WebDeploymentService.doStart(WebDeploymentService.java:156) [jboss-as-web-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> at org.jboss.as.web.deployment.WebDeploymentService.access$000(WebDeploymentService.java:60) [jboss-as-web-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> at org.jboss.as.web.deployment.WebDeploymentService$1.run(WebDeploymentService.java:93) [jboss-as-web-7.3.0.Final-redhat-14.jar:7.3.0.Final-redhat-14]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_21]
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_21]
> at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> {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
10 years, 10 months