[JBoss JIRA] (AS7-3260) Deplyoment distribution fails when DC is Windows and HC is linux
by Tomaz Cerar (Created) (JIRA)
Deplyoment distribution fails when DC is Windows and HC is linux
----------------------------------------------------------------
Key: AS7-3260
URL: https://issues.jboss.org/browse/AS7-3260
Project: Application Server 7
Issue Type: Bug
Components: Domain Management
Affects Versions: 7.1.0.CR1b
Environment: HC on linux
DC on windows 7
Reporter: Tomaz Cerar
Assignee: Brian Stansberry
Priority: Critical
Fix For: 7.1.0.Final
There is problem with the distribution of the content (deployments) between the DC running on Windows 7 and the slaves running on CentOS/RHEL 6.2. The content is distributed to the slaves, but the filename "content" in content sub directories is prefixed with "\", as "\content". If I rename the file to "content", the host picks up the correct deployment after restart.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (AS7-3231) Property jboss.entity.manager.factory.jndi.name not working
by Zbyněk Roubalík (Created) (JIRA)
Property jboss.entity.manager.factory.jndi.name not working
-----------------------------------------------------------
Key: AS7-3231
URL: https://issues.jboss.org/browse/AS7-3231
Project: Application Server 7
Issue Type: Bug
Components: JPA / Hibernate
Affects Versions: 7.1.0.CR1
Reporter: Zbyněk Roubalík
Assignee: Scott Marlow
Fix For: 7.1.0.Final
If there is specified property jboss.entity.manager.factory.jndi.name in persistence.xml file, it isn't possible to deploy application using this file.
I've create test for this issue:
https://github.com/zroubalik/jboss-as/blob/emfBind/testsuite/integration/...
Error on output from this tests:
21:15:38,732 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC00001: Failed to start service jboss.deployment.unit."jpa_emfactory.jar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."jpa_emfactory.jar".INSTALL: Failed to process phase INSTALL of deployment "jpa_emfactory.jar"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:121) [jboss-as-server-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1824) [jboss-msc-1.0.1.GA.jar:1.0.1.GA]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1759) [jboss-msc-1.0.1.GA.jar:1.0.1.GA]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [:1.6.0_20]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [:1.6.0_20]
at java.lang.Thread.run(Thread.java:636) [:1.6.0_20]
Caused by: java.lang.NullPointerException
at org.jboss.as.jpa.processor.PersistenceUnitDeploymentProcessor.addPuService(PersistenceUnitDeploymentProcessor.java:329)
at org.jboss.as.jpa.processor.PersistenceUnitDeploymentProcessor.handleJarDeployment(PersistenceUnitDeploymentProcessor.java:139)
at org.jboss.as.jpa.processor.PersistenceUnitDeploymentProcessor.deploy(PersistenceUnitDeploymentProcessor.java:120)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115) [jboss-as-server-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]
... 5 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (AS7-2409) host.xml host name should default to something unique
by Rich Sharples (Created) (JIRA)
host.xml host name should default to something unique
-----------------------------------------------------
Key: AS7-2409
URL: https://issues.jboss.org/browse/AS7-2409
Project: Application Server 7
Issue Type: Enhancement
Components: Clustering
Affects Versions: 7.1.0.Alpha1
Environment: all
Reporter: Rich Sharples
Assignee: Paul Ferraro
Fix For: 7.1.0.Beta1
in a distribibuted domain environment (ie. typical production env.) host name in host.xml must be unique :
<host xmlns="urn:jboss:domain:1.1"
name="RichS">
otherwise we get a startup error. To avoid having to modify this config for all machines (could be 10^3), we need a way to default this to a unique id. One idea would be to have a UUID property generated from the host-ip + process-id. That would provide unique IDs across the domain and also allow multiple instances per machine.
In domain mode this really should be the default (ie. we shold always use the property in domain/configuration/host.xml).
Note : if we do use host-ip+process-id then the ID is going to be different every time the process start - that may be a problem in itself.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (AS7-3036) Remove OSGi bundles that cannot be supported
by Thomas Diesler (Issue Comment Edited) (JIRA)
[ https://issues.jboss.org/browse/AS7-3036?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler edited comment on AS7-3036 at 1/10/12 5:42 AM:
--------------------------------------------------------------
Removed
- <version.org.apache.aries.jmx>0.3</version.org.apache.aries.jmx>
- <version.org.apache.felix.log>1.0.0</version.org.apache.felix.log>
- <version.org.apache.felix.eventadmin>1.2.6</version.org.apache.felix.eventadmin>
- <version.org.apache.felix.metatype>1.0.4</version.org.apache.felix.metatype>
- <version.org.apache.felix.scr>1.6.0</version.org.apache.felix.scr>
- <version.org.apache.felix.webconsole>3.1.6.SP1</version.org.apache.felix.webconsole>
- <version.org.jboss.osgi.blueprint>1.0.3</version.org.jboss.osgi.blueprint>
- <version.org.jboss.osgi.http>1.0.5</version.org.jboss.osgi.http>
- <version.org.jboss.osgi.jmx>1.0.10</version.org.jboss.osgi.jmx>
- <version.org.jboss.osgi.logging>1.0.0</version.org.jboss.osgi.logging>
- <version.org.jboss.osgi.webapp>1.0.5</version.org.jboss.osgi.webapp>
- <version.org.jboss.osgi.webconsole>1.0.6</version.org.jboss.osgi.webconsole>
- <version.org.jboss.osgi.xerces>2.9.1.SP7</version.org.jboss.osgi.xerces>
was (Author: thomas.diesler):
{code}
- <version.org.apache.aries.jmx>0.3</version.org.apache.aries.jmx>
- <version.org.apache.felix.log>1.0.0</version.org.apache.felix.log>
- <version.org.apache.felix.eventadmin>1.2.6</version.org.apache.felix.eventadmin>
- <version.org.apache.felix.metatype>1.0.4</version.org.apache.felix.metatype>
- <version.org.apache.felix.scr>1.6.0</version.org.apache.felix.scr>
- <version.org.apache.felix.webconsole>3.1.6.SP1</version.org.apache.felix.webconsole>
- <version.org.jboss.osgi.blueprint>1.0.3</version.org.jboss.osgi.blueprint>
- <version.org.jboss.osgi.http>1.0.5</version.org.jboss.osgi.http>
- <version.org.jboss.osgi.jmx>1.0.10</version.org.jboss.osgi.jmx>
- <version.org.jboss.osgi.logging>1.0.0</version.org.jboss.osgi.logging>
- <version.org.jboss.osgi.webapp>1.0.5</version.org.jboss.osgi.webapp>
- <version.org.jboss.osgi.webconsole>1.0.6</version.org.jboss.osgi.webconsole>
- <version.org.jboss.osgi.xerces>2.9.1.SP7</version.org.jboss.osgi.xerces>
{code}
> Remove OSGi bundles that cannot be supported
> --------------------------------------------
>
> Key: AS7-3036
> URL: https://issues.jboss.org/browse/AS7-3036
> Project: Application Server 7
> Issue Type: Task
> Components: OSGi
> Reporter: Thomas Diesler
> Assignee: Thomas Diesler
> Fix For: 7.1.0.Final
>
>
> Currently we have:
> * Webconsole, provided by Felix (requires HttpService)
> * HttpService, provided by PaxWeb (runs on Jetty)
> * Webapp support, provided by PaxWeb (runs on Jetty)
> * LogService, provided by Felix
> * ConfigAdmin service, provided by Felix
> * JMX services, provided by Aries
> * EventAdmin, provided by Felix
> * DeclarativServices, provided by Felix
> * STOMP endpoints (Stilts), provided by JBoss
> * Blueprint, provided by Aries
> * XML parsing, provided by JBoss
> * JNDI support, provided by JBoss
> * JTA support, provided by JBoss
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (JBRULES-3337) Broken accumulate function - possible WM corruption
by Martin Vecera (Created) (JIRA)
Broken accumulate function - possible WM corruption
---------------------------------------------------
Key: JBRULES-3337
URL: https://issues.jboss.org/browse/JBRULES-3337
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-core (expert), drools-planner
Affects Versions: 5.4.0.Beta1, 5.3.1.Final, 5.3.0.Final
Environment: Linux x86_64, Oracle JDK 7
Reporter: Martin Vecera
Assignee: Geoffrey De Smet
Using Drools Planner, I created a planning solution for planning matches on tournaments. When I created a score calculating rule using the accumulate function, I realized that it behaves very strange. This is possibly because of Working Memory corruption. I think so, because I need to performa several changes in WM to recreate the problem. When I use only the last state of WM and put it in a freshly instantiated WM, it works fine.
Attached is an reproducer application. You can just unzip and run 'mvn test'. The test does not fail, but you can see the corruption in its output.
First, I would like to describe the solution. There are the following entities - Team, Group (a group of teams, usually only teams in the same group play together), Court, Match (between teams), and Slot (Slot connects a numbered time slot on a particular Court). A Match can be assigned to a Slot to denote which teams are supposed to play a match at the given court in the given time.
All of the teams, groups, courts, and maches appear in the WM at the beginning. Planner then adds slots and tries to assign Matches to the slots.
The test executed by 'mvn test', fills a WM with specific facts. Then it adds a Slot with some assignment and fires all rules. After that, different match is assigned to the slot and all rules are fired again. The last step is repeated several times.
The problematic rule is the following one:
{noformat}
rule "Get overhead per team"
when
$t: Team()
accumulate(
$s: Slot($num: number, match != null, $ts: teams, teams contains $t),
$min: min($num),
$max: max($num),
$slist: collectList($s),
$sset: collectSet($s),
$tslist: collectList($ts), // this collects all team sets, each set
$count: count($s)
)
then
System.out.println("= START = rule Get overhead per team");
System.out.println("Working with team " + $t.toString() + ", it must appear in each subset of the following set: " + Arrays.toString($tslist.toArray()));
System.out.println("The same team must appear in the match associated with each of the following slots:");
System.out.println(Arrays.toString($slist.toArray()));
System.out.println("Each slot should be considered only once, we should not have duplicates in the previous list.");
System.out.println("= END = rule Get overhead per team");
// ((max - min + 1) / min_slots_per_match) - count
insertLogical(
new IntConstraintOccurrence("teamOverhead", ConstraintType.NEGATIVE_SOFT,
$sset.size() < 2 ? 0 :
Math.max(0, (($max.intValue() - $min.intValue() + 1) / 2 - $sset.size())), $t, $slist)
);
end
{noformat}
Its main goal is for each team to collect all slots that has a match assigned in which this team has to play (Slot -> Match -> Teams_in_match contains Team).
Some data is collected for each Slot - most of these are just to show the bug. As you can see, only Slots that fulfills the condition 'teams contains $t' can be taken into account.
$ts refers to the set teams in this Slot. A list of these sets is collected ($tslist). On the RHS, this rule contains some debug output. It mainly prints out the team ($t) and the list of team sets (list of all $ts). According to the rule condition, each set in $tslist must contain the team $t. However, this is not true as you can see from the test output after 4th rules firing:
{noformat}
= START = rule Get overhead per team
Working with team Team X0, it must appear in each subset of the following set: [[Team X1, Team X2]]
The same team must appear in the match associated with each of the following slots:
[Slot [Court A, 0, match=Match [teamsInMatch=[Team X1, Team X2]]]]
Each slot should be considered only once, we should not have duplicates in the previous list.
= END = rule Get overhead per team
{noformat}
Team X0 does not appear in [Team X1, Team X2]. Because of that, wrong Slots are taken into account and the rule breaks the score.
Another problem is that the list of collected slots ($slist) and the set of collected slots ($sset) differ in size. The list simply contains some duplicates and this means that some Slots were considered multiple times. This can be seen after 3nd rules firing:
{noformat}
= START = rule Get overhead per team
Working with team Team X0, it must appear in each subset of the following set: [[Team X0, Team X2], [Team X0, Team X3]]
The same team must appear in the match associated with each of the following slots:
[Slot [Court A, 0, match=Match [teamsInMatch=[Team X0, Team X3]]], Slot [Court A, 0, match=Match [teamsInMatch=[Team X0, Team X3]]]]
Each slot should be considered only once, we should not have duplicates in the previous list.
= END = rule Get overhead per team
{noformat}
You can see the duplicate Slot in the list. I tried running equals() on them and they are equal. On the other hand, a Slot with teams X0 and X2 must have been considered because it appears in the list of $ts sets ([[Team X0, Team X2], [Team X0, Team X3]]). How is this possible? We no longer have a Slot assigned with the match between team X0 and X2.
Each step of rules firing produces an output in the following format:
{noformat}
= Run no. X ============================================
= START = rule Get overhead per team
...
= END = rule Get overhead per team
... several executions of the rule ...
X) ... content of WM after firing the rules...
X) ...
{noformat}
In the output you can see all constraints that were created base on the WM content.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (JBRULES-3339) A special case that drl couldn't compile when using 'contains' operator on a value which is get from a external literal map
by Miles Wen (Created) (JIRA)
A special case that drl couldn't compile when using 'contains' operator on a value which is get from a external literal map
---------------------------------------------------------------------------------------------------------------------------
Key: JBRULES-3339
URL: https://issues.jboss.org/browse/JBRULES-3339
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-compiler (expert)
Affects Versions: 5.3.0.Final
Environment: sun jdk 1.6u27, unbuntu linux 11.04 amd64, drools 5.3.0 final
Reporter: Miles Wen
Assignee: Mark Proctor
This code couldn't compile:
package com.sample
import com.sample.Msg;
import java.util.Map;
import java.util.Date;
global java.util.Map literalMap;
rule "out"
when
Msg(true || set contains ((Date)literalMap.get("date")))
then
end
which emits error msg:
Unable to Analyse Expression true || set contains ((Date)literalMap.get("date")):
[Error: unable to resolve method using strict-mode: com.sample.Msg.contains(java.util.Date)]
[Near : {... true || set contains ((Date)literalMap.get ....}]
^
[Line: 16, Column: 9] : [Rule name='out']
java.lang.IllegalArgumentException: Could not parse knowledge.
at com.sample.DroolsTest.readKnowledgeBase(DroolsTest.java:82)
at com.sample.DroolsTest.main(DroolsTest.java:34)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] Created: (JBAS-9229) hibernate fails to bind session factory name to jndi
by George Sapountzis (JIRA)
hibernate fails to bind session factory name to jndi
----------------------------------------------------
Key: JBAS-9229
URL: https://issues.jboss.org/browse/JBAS-9229
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JPA / Hibernate
Affects Versions: 7.0.0.Beta2
Reporter: George Sapountzis
Assignee: Scott Marlow
Put the following line in persistence.xml:
<property name="hibernate.session_factory_name" value="modelSessionFactory" />
Hibernate fails to bind modelSessionFactory.
Remove the following two lines from HibernatePersistenceProviderAdaptor.java
- properties.put("hibernate.jndi.java.naming.factory.initial", "org.jnp.interfaces.NamingContextFactory");
- properties.put("hibernate.jndi.java.naming.factory.url.pkgs", "org.jboss.naming:org.jnp.interfaces");
Then the bindind succeeds.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months