[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
14 years, 3 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
14 years, 3 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
14 years, 3 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
14 years, 3 months
[JBoss JIRA] (SECURITY-639) DatabaseRolesMappingProvider fails when no roles are present for user
by Kory Markevich (Created) (JIRA)
DatabaseRolesMappingProvider fails when no roles are present for user
---------------------------------------------------------------------
Key: SECURITY-639
URL: https://issues.jboss.org/browse/SECURITY-639
Project: PicketBox (JBoss Security and Identity Management)
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: PicketBox
Affects Versions: PicketBox_v4_0_1
Environment: JBoss AS 7.0.1
Reporter: Kory Markevich
Assignee: Anil Saldhana
When using DatabaseRolesMappingProvider as part of a web app, everything works fine if the query returns at least one role. If the user does not have any (a valid case in our system) then an IllegalArgumentException is thrown, which is not caught and aborts the authentication process (see stack trace at bottom.)
In particular the Util.addRolesToGroup method explicitly checks for the no-role case, but only to for logging purposes, and then continues on trying to read the roles. This will obviously always fail as per JDBC specs. It looks like the reading should have been put inside an else clause.
15:55:55,700 ERROR [org.apache.catalina.connector.CoyoteAdapter] (http--127.0.0.1-8080-4) An exception or error occurred in the container during the request processing: java.lang.IllegalArgumentException: Query failed
at org.jboss.security.mapping.providers.role.Util.addRolesToGroup(Util.java:250) [picketbox-4.0.1.jar:4.0.1]
at org.jboss.security.mapping.providers.role.DatabaseRolesMappingProvider.performMapping(DatabaseRolesMappingProvider.java:100) [picketbox-4.0.1.jar:4.0.1]
at org.jboss.security.mapping.providers.role.DatabaseRolesMappingProvider.performMapping(DatabaseRolesMappingProvider.java:42) [picketbox-4.0.1.jar:4.0.1]
at org.jboss.security.mapping.MappingContext.performMapping(MappingContext.java:54) [picketbox-4.0.1.jar:4.0.1]
at org.jboss.security.plugins.JBossAuthorizationManager.getCurrentRoles(JBossAuthorizationManager.java:396) [picketbox-4.0.1.jar:4.0.1]
at org.jboss.security.plugins.JBossAuthorizationManager.getSubjectRoles(JBossAuthorizationManager.java:323) [picketbox-4.0.1.jar:4.0.1]
at org.jboss.as.web.security.JBossWebRealm.authenticate(JBossWebRealm.java:144) [jboss-as-web-7.0.1.Final.jar:7.0.1.Final]
at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:280) [jbossweb-7.0.1.Final.jar:7.0.1.Final]
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:372) [jbossweb-7.0.1.Final.jar:7.0.1.Final]
at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57) [jboss-as-web-7.0.1.Final.jar:7.0.1.Final]
at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:49) [jboss-as-jpa-7.0.1.Final.jar:7.0.1.Final]
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154) [jbossweb-7.0.1.Final.jar:7.0.1.Final]
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.1.Final.jar:7.0.1.Final]
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.1.Final.jar:7.0.1.Final]
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.1.Final.jar:7.0.1.Final]
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.1.Final.jar:7.0.1.Final]
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:667) [jbossweb-7.0.1.Final.jar:7.0.1.Final]
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:952) [jbossweb-7.0.1.Final.jar:7.0.1.Final]
at java.lang.Thread.run(Thread.java:662) [:1.6.0_29]
Caused by: java.sql.SQLException: Exhausted Resultset
at oracle.jdbc.driver.OracleResultSetImpl.getString(OracleResultSetImpl.java:1270)
at org.jboss.jca.adapters.jdbc.WrappedResultSet.getString(WrappedResultSet.java:1338)
at org.jboss.security.mapping.providers.role.Util.addRolesToGroup(Util.java:239) [picketbox-4.0.1.jar:4.0.1]
... 18 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
14 years, 3 months
[JBoss JIRA] (AS7-3218) read-resource with include-runtime fails for OSGi on HC
by Kabir Khan (Created) (JIRA)
read-resource with include-runtime fails for OSGi on HC
-------------------------------------------------------
Key: AS7-3218
URL: https://issues.jboss.org/browse/AS7-3218
Project: Application Server 7
Issue Type: Bug
Components: OSGi
Reporter: Kabir Khan
Assignee: Thomas Diesler
Priority: Critical
Fix For: 7.1.0.Final
{code}
[domain@localhost:9999 /] :read-resource(recursive-depth=2,include-runtime=true)
{
"outcome" => "failed",
"rolled-back" => true
}
{code}
log:
{code}
[Host Controller] 10:39:54,263 ERROR [org.jboss.as.controller.management-operation] (management-handler-threads - 2) JBAS014612: Operation ("read-attribute") failed - address: ([
[Host Controller] ("profile" => "ha"),
[Host Controller] ("subsystem" => "osgi")
[Host Controller] ]): org.jboss.msc.service.ServiceNotFoundException: Service service jbosgi.StartLevel not found
[Host Controller] at org.jboss.msc.service.ServiceContainerImpl.getRequiredService(ServiceContainerImpl.java:447) [jboss-msc-1.0.1.GA.jar:1.0.1.GA]
[Host Controller] at org.jboss.as.osgi.parser.StartLevelHandler.execute(StartLevelHandler.java:58)
[Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:359) [jboss-as-controller-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]
[Host Controller] at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:254) [jboss-as-controller-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]
[Host Controller] at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:190) [jboss-as-controller-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]
{code}
--
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
14 years, 3 months