[JBoss JIRA] (WFLY-2838) Revisit default mod_cluster metric for WildFly 8
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-2838?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-2838:
--------------------------------------
JFC would prefer autogenerating capacity of the busyness metric (e.g. in JBW it is 128 requests per sec per CPU) [or session.]
> Revisit default mod_cluster metric for WildFly 8
> ------------------------------------------------
>
> Key: WFLY-2838
> URL: https://issues.jboss.org/browse/WFLY-2838
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.0.0.CR1
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Blocker
> Fix For: 8.0.0.Final
>
>
> Since the threading aspects of Undertow in WildFly are completely different from JBoss Web's in the previous versions of AS, we should reconsider the default metric for WildFly.
> Currently, busyness requires explicit capacity to be useful which would require further tweaking by users.
> Metric "cpu" is also a good candidate since it doesn't need explicit capacity..
--
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, 2 months
[JBoss JIRA] (WFLY-2838) Revisit default mod_cluster metric for WildFly 8
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-2838?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-2838:
--------------------------------------
Stuart is fine with CPU.
> Revisit default mod_cluster metric for WildFly 8
> ------------------------------------------------
>
> Key: WFLY-2838
> URL: https://issues.jboss.org/browse/WFLY-2838
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.0.0.CR1
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Blocker
> Fix For: 8.0.0.Final
>
>
> Since the threading aspects of Undertow in WildFly are completely different from JBoss Web's in the previous versions of AS, we should reconsider the default metric for WildFly.
> Currently, busyness requires explicit capacity to be useful which would require further tweaking by users.
> Metric "cpu" is also a good candidate since it doesn't need explicit capacity..
--
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, 2 months
[JBoss JIRA] (DROOLS-383) switch over String in function
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-383?page=com.atlassian.jira.plugin... ]
Mario Fusco commented on DROOLS-383:
------------------------------------
The problem is not only in functions. It happens exactly the same if you try to use the switch over String directly in a consequence.
That error message is generated by the Eclipse Java Compiler the we are using internally at the moment.
The only way to fix this is to migrate to the native Java compiler that it is something that we have already planned.
This is only a reason more to make this migration asap.
> switch over String in function
> ------------------------------
>
> Key: DROOLS-383
> URL: https://issues.jboss.org/browse/DROOLS-383
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.0.Final
> Reporter: Matteo Mortari
> Assignee: Mark Proctor
> Attachments: 20131219.drools6scratch-switchoverstring.zip
>
>
> *Executive Summary*: if I try to implement switch over String as per Java 1.7, inside of DRL function, compilation of DRL fails, but the error message would suggest that actually switch over String should work.
> *Steps to reproduce*
> Have a DRL file with function with String parameter and inside the function a switch over the parameter, for example
> {code:title=acme.drl|borderStyle=solid}
> rule "Stupid rule over String"
> when
> String()
> then
> System.out.println("Hello world");
> end
> function void theTest(String input) {
> switch(input) {
> case "Hello World" :
> System.out.println("yep");
> break;
> default :
> System.out.println("uh");
> break;
> }
> }
> {code}
> Have simple code to compile DRL for default KieBase, for example snippet:
> {code:title=App.java|borderStyle=solid}
> String input = "Hello World";
> // Java 1.7
> switch(input) {
> case "Hello World" :
> System.out.println("yep");
> break;
> default :
> System.out.println("uh");
> break;
> }
> System.out.println( "Hello World!" );
> KieServices ks = KieServices.Factory.get();
> KieContainer kContainer = ks.getKieClasspathContainer();
> KieBase kieBase = kContainer.getKieBase();
> for ( KiePackage kp : kieBase.getKiePackages() ) {
> for (Rule rule : kp.getRules()) {
> System.out.println("kp" + kp + " rule " + rule.getName());
> }
> }
> {code}
> Console would log DRL compile fails with error:
> {noformat}
> Exception in thread "main" java.lang.RuntimeException: Error while creating KieBase[Message [id=1, level=ERROR, path=acme.drl, line=-1, column=0
> text=Error importing : 'defaultpkg.TheTest.theTest'], Message [id=2, level=ERROR, path=acme.drl, line=8, column=0
> text=[ function theTesttheTest (line:8): Cannot switch on a value of type String. Only convertible int values, strings or enum constants are permitted
> ]], Message [id=3, level=ERROR, path=acme.drl, line=1, column=0
> text=Rule Compilation error The import defaultpkg.TheTest cannot be resolved]]
> {noformat}
> Please notice the 'strings' bit in the error message : {{Cannot switch on a value of type String. Only convertible int values, *strings* or enum constants are permitted}}
> Therefore would suggest it would compile a switch over String, but for some reason it is failing to recognize that input parameter is indeed a String?
> Thank you
> Ciao
> MM
--
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, 2 months
[JBoss JIRA] (WFLY-2785) master reload on windows using bind IP without a reverse DNS entry (or a wrong one)
by Aleksandar Kostadinov (JIRA)
[ https://issues.jboss.org/browse/WFLY-2785?page=com.atlassian.jira.plugin.... ]
Aleksandar Kostadinov closed WFLY-2785.
---------------------------------------
Fix Version/s: 8.0.0.Final
Resolution: Done
> master reload on windows using bind IP without a reverse DNS entry (or a wrong one)
> -----------------------------------------------------------------------------------
>
> Key: WFLY-2785
> URL: https://issues.jboss.org/browse/WFLY-2785
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Server
> Affects Versions: 8.0.0.CR1
> Environment: windows
> Reporter: Aleksandar Kostadinov
> Assignee: Aleksandar Kostadinov
> Labels: addressing, domain, socket
> Fix For: 8.0.0.Final
>
> Attachments: server_logs.zip
>
>
> When running on windows and the server management port bind IP address does not have a proper reverse DNS entry or an entry in the hosts file, then there is trouble reloading the server. It is possible that same issue may affect other domain server management operations but I didn't identify any others (and didn't try).
> Basically the problem is that windows reverse resolves such IPs to the computer name. On reload without restarting the managed servers, they receive as a host to reconnect to the computer name instead of the IP address and connection cannot be established.
> Here is how to reproduce:
> # on a windows machine add some local IP address without a reverse entry (e.g. 192.0.2.15)
> # launch domain server from wildfly, e.g.: bin/domain.sh -bpublic=192.0.2.15 -bmanagement=192.0.2.15
> # issue this cli command: reload --restart-servers=false --host=master
> # see logs for messages from server-one and server-two (I'll attach an archive with such logs)
> The fix I found for the issue is:{CODE}
> diff --git a/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java b/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
> index 308df0e..c6a88e8 100644
> --- a/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
> +++ b/host-controller/src/main/java/org/jboss/as/host/controller/ManagedServer.java
> @@ -30,7 +30,6 @@ import static org.jboss.as.host.controller.HostControllerLogger.ROOT_LOGGER;
>
> import java.io.IOException;
> import java.io.OutputStream;
> -import java.net.InetAddress;
> import java.net.InetSocketAddress;
> import java.util.Collections;
> import java.util.LinkedHashMap;
> @@ -769,7 +768,7 @@ class ManagedServer {
> public boolean execute(ManagedServer server) throws Exception {
> assert Thread.holdsLock(ManagedServer.this); // Call under lock
> // Reconnect
> - final String hostName = InetAddress.getByName(managementSocket.getHostName()).getHostName();
> + final String hostName = managementSocket.getHostString();
> final int port = managementSocket.getPort();
> processControllerClient.reconnectProcess(serverProcessName, NetworkUtils.formatPossibleIpv6Address(hostName), port, bootConfiguration.isManagementSubsystemEndpoint(), authKey);
> return true;
> {CODE}
> I see that the line causing the troubles was [committed|https://github.com/wildfly/wildfly/commit/7effc2eca6cfd5d031a05...] as part of AS7-3613. I looked at the issue and I don't see how this altering of hostname can help with getting a good URI. Yes, it can help if it guaranteed that a hostname will always be returned but fact is that on linux, if reverse record is missing or improper, this still returns an IP so this line of code IMO can only cause harm. Am I missing something?
> Moreover it doesn't seems right to me to change server identification overriding user choice to select an IP instead of a hostname just to fix some URIs.
> IMO if user/administrator used an IP, then server should to use it as an IP, not reverse resolve it to a host and then use it. It simply leads to confusion.
--
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, 2 months
[JBoss JIRA] (WFLY-2522) Error when invoking @Remove method for stateful bean in transaction
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-2522?page=com.atlassian.jira.plugin.... ]
Stuart Douglas updated WFLY-2522:
---------------------------------
Priority: Major (was: Blocker)
Steps to Reproduce:
1- Download projects from http://www.filedropper.com/jbosstxsyncerror
The zip contains 3 projects
JBossTxSyncError : EJB Project
JBossTxSyncErrorClient : EJB Client Project
JBossTxSyncErrorEar : Ear project
2- Import project into Eclipse
3- add required libraries in build path
JBossTxSyncError
JBoss 7.1 Runtime
JBossTxSyncErrorClient
jboss-client.jar
jboss-ejb-api_3.1_spec-1.0.2.Final.jar
4- create table using create.sql file under JBossTxSyncErrorClient
5- configure jboss-ejb-client.properties file under JBossTxSyncErrorClient
6- configure a datasource for mysql connection
7- enter datasource Jndi name in file messages.properties under JBossTxSyncError project in key EmployeeBean.datasourceJndi
8- deploy ear file and run OldEjbClient.java
was:
1- Download projects from http://www.filedropper.com/jbosstxsyncerror
The zip contains 3 projects
JBossTxSyncError : EJB Project
JBossTxSyncErrorClient : EJB Client Project
JBossTxSyncErrorEar : Ear project
2- Import project into Eclipse
3- add required libraries in build path
JBossTxSyncError
JBoss 7.1 Runtime
JBossTxSyncErrorClient
jboss-client.jar
jboss-ejb-api_3.1_spec-1.0.2.Final.jar
4- create table using create.sql file under JBossTxSyncErrorClient
5- configure jboss-ejb-client.properties file under JBossTxSyncErrorClient
6- configure a datasource for mysql connection
7- enter datasource Jndi name in file messages.properties under JBossTxSyncError project in key EmployeeBean.datasourceJndi
8- deploy ear file and run OldEjbClient.java
This only occurs if you attempt to remove an EJB in a transaction synchronization callback.
> Error when invoking @Remove method for stateful bean in transaction
> -------------------------------------------------------------------
>
> Key: WFLY-2522
> URL: https://issues.jboss.org/browse/WFLY-2522
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Affects Versions: 8.0.0.Beta1
> Reporter: noel a.a
> Assignee: David Lloyd
>
> I'm invoking method annotated with @Remove
> {code}
> @Remove
> public void remove() {
> ...
> {code}
> On invocation inside active transaction I'm getting following error :
> {noformat}
> Caused by: java.lang.IllegalStateException: ARJUNA016082: Synchronizations are not allowed! Transaction status isActionStatus.RUNNING
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronizationImple(TransactionImple.java:374)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.registerSynchronization(TransactionImple.java:351)
> at org.jboss.as.ejb3.cache.TransactionAwareObjectFactory.destroyInstance(TransactionAwareObjectFactory.java:66) [jboss-as-ejb3-7.1.3.Final.jar:7.1.3.Final]
> at org.jboss.as.ejb3.cache.impl.backing.NonPassivatingBackingCacheImpl.remove(NonPassivatingBackingCacheImpl.java:165) [jboss-as-ejb3-7.1.3.Final.jar:7.1.3.Final]
> at org.jboss.as.ejb3.cache.impl.backing.NonPassivatingBackingCacheImpl.remove(NonPassivatingBackingCacheImpl.java:57) [jboss-as-ejb3-7.1.3.Final.jar:7.1.3.Final]
> at org.jboss.as.ejb3.cache.spi.impl.AbstractCache.remove(AbstractCache.java:100) [jboss-as-ejb3-7.1.3.Final.jar:7.1.3.Final]
> at org.jboss.as.ejb3.cache.spi.impl.AbstractCache.remove(AbstractCache.java:39) [jboss-as-ejb3-7.1.3.Final.jar:7.1.3.Final]
> at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.removeSession(StatefulSessionComponent.java:283) [jboss-as-ejb3-7.1.3.Final.jar:7.1.3.Final]
> at org.jboss.as.ejb3.component.stateful.StatefulRemoveInterceptor.processInvocation(StatefulRemoveInterceptor.java:100) [jboss-as-ejb3-7.1.3.Final.jar:7.1.3.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:67) [jboss-as-ejb3-7.1.3.Final.jar:7.1.3.Final]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:200) [jboss-as-ejb3-7.1.3.Final.jar:7.1.3.Final]
> ... 140 more
> {noformat}
> EJB Spec paragraphe 4.6.4 states:
> {quote}
> If a session bean instance is participating in a transaction, it is an error for a client to invoke the remove method on the session object’s home or component interface object. The container must detect such an attempt and throw the javax.ejb.RemoveException to the client. The container should not mark the client’s transaction for rollback, thus allowing the client to recover. Note that this restriction only applies to the remove method on the session object’s home or component interface, not to the invocation of @Remove methods.
> {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, 2 months
[JBoss JIRA] (JBMETA-373) [backport JBMETA-371] DefaultPropertyReplacer + PropertyResolver is broken for vault expressions
by Chris Dolphy (JIRA)
[ https://issues.jboss.org/browse/JBMETA-373?page=com.atlassian.jira.plugin... ]
Chris Dolphy commented on JBMETA-373:
-------------------------------------
Pull request to add JBMETA-371 to 7.0.9
https://github.com/jboss/metadata/pull/58
> [backport JBMETA-371] DefaultPropertyReplacer + PropertyResolver is broken for vault expressions
> ------------------------------------------------------------------------------------------------
>
> Key: JBMETA-373
> URL: https://issues.jboss.org/browse/JBMETA-373
> Project: JBoss Metadata
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: common
> Affects Versions: 7.0.4.Final
> Reporter: Chris Dolphy
> Assignee: Brian Stansberry
>
> The DefaultPropertyReplacer + PropertyResolver algorithm is broken for vault expressions. It's based on the assumption that the contents of the expression string between "${" and "}" have a fixed format a la the old JBoss AS system properties (e.g. propertyname[: default value]) and then the PropertyResolver tries to resolve "propertyname".
> This is incorrect in the case of vault expressions, which do not follow this format. In particular the ":" char appears multiple places in a vault expression and does not serve as a delimiter between "propertyname" and "default value".
--
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, 2 months
[JBoss JIRA] (WFLY-2851) Can't validate jboss-deployment-structure.xml due to incorrect schema
by Harald Wellmann (JIRA)
[ https://issues.jboss.org/browse/WFLY-2851?page=com.atlassian.jira.plugin.... ]
Harald Wellmann updated WFLY-2851:
----------------------------------
Description:
The following deployment structure cannot be validated against the XML schema:
{code:xml}
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
<deployment>
<dependencies>
<module name="foo"/>
</dependencies>
</deployment>
</jboss-deployment-structure>
{code}
This looks like a glitch in the schema where the {{module-alias}} element in {{deploymentType}} is missing a {{minOccurs="0"}}.
The same holds for the {{filter}} element of {{resource-root}}, which should be optional according to the schema documentation.
was:
The following deployment structure cannot be validated against the XML schema:
{code:xml}
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
<deployment>
<dependencies>
<module name="foo"/>
</dependencies>
</deployment>
</jboss-deployment-structure>
{code}
This looks like a glitch in the schema where the {{module-alias}} element in {{deploymentType}} is missing a {{minOccurs="0"}}.
> Can't validate jboss-deployment-structure.xml due to incorrect schema
> ---------------------------------------------------------------------
>
> Key: WFLY-2851
> URL: https://issues.jboss.org/browse/WFLY-2851
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 8.0.0.CR1
> Reporter: Harald Wellmann
>
> The following deployment structure cannot be validated against the XML schema:
> {code:xml}
> <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
> <deployment>
> <dependencies>
> <module name="foo"/>
> </dependencies>
> </deployment>
> </jboss-deployment-structure>
> {code}
> This looks like a glitch in the schema where the {{module-alias}} element in {{deploymentType}} is missing a {{minOccurs="0"}}.
> The same holds for the {{filter}} element of {{resource-root}}, which should be optional according to the schema documentation.
--
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, 2 months
[JBoss JIRA] (WFLY-2851) Can't validate jboss-deployment-structure.xml due to incorrect schema
by Harald Wellmann (JIRA)
Harald Wellmann created WFLY-2851:
-------------------------------------
Summary: Can't validate jboss-deployment-structure.xml due to incorrect schema
Key: WFLY-2851
URL: https://issues.jboss.org/browse/WFLY-2851
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 8.0.0.CR1
Reporter: Harald Wellmann
The following deployment structure cannot be validated against the XML schema:
{code:xml}
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
<deployment>
<dependencies>
<module name="foo"/>
</dependencies>
</deployment>
</jboss-deployment-structure>
{code}
This looks like a glitch in the schema where the {{module-alias}} element in {{deploymentType}} is missing a {{minOccurs="0"}}.
--
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, 2 months
[JBoss JIRA] (WFLY-1901) Could not grant javax.xml.ws.WebServicePermission to a deployment
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-1901?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-1901:
--------------------------------------
In my PR I have added a module attribute that allows you to specify the module to load the permission from.
> Could not grant javax.xml.ws.WebServicePermission to a deployment
> -----------------------------------------------------------------
>
> Key: WFLY-1901
> URL: https://issues.jboss.org/browse/WFLY-1901
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Security Manager
> Affects Versions: 8.0.0.Alpha4
> Reporter: Alessio Soldano
> Assignee: Stefan Guilhen
> Fix For: 8.0.0.Final
>
>
> It's currently not possible by default to grant the javax.xml.ws.WebServicePermission "publish" permission to a user deployment by adding the proper entry in standalone.xml:
> {noformat}
> <subsystem xmlns="urn:jboss:domain:security-manager:1.0">
> <deployment-permissions>
> <minimum-set>
> ...
> <permission class="javax.xml.ws.WebServicePermission" name="publishEndpoint"/>
> </minimum-set>
> </deployment-permissions>
> </subsystem>
> {noformat}
--
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, 2 months