July 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (AS7-1345) sub-deployment declared as wrong type in jboss-deployment-structure-1_0.xsd

by Darrin Mison (JIRA)

sub-deployment declared as wrong type in jboss-deployment-structure-1_0.xsd --------------------------------------------------------------------------- Key: AS7-1345 URL: https://issues.jboss.org/browse/AS7-1345 Project: Application Server 7 Issue Type: Bug Affects Versions: 7.0.0.Final Reporter: Darrin Mison I suspect that this is a typo in docs/schema/jboss-deployment-structure-1_0.xsd On line 82, should the type of sub-deployment element be "subDeploymentType" ? <xsd:element name="sub-deployment" type="deploymentType" minOccurs="0" maxOccurs="unbounded" > subDeploymentType is declared on line 149 but doesn't seem to be used. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 12 months

4
5
0 / 0

[JBoss JIRA] Created: (JGRP-1001) Use ByteMan / Metronome to inject faults for testing

by Bela Ban (JIRA)

Use ByteMan / Metronome to inject faults for testing ---------------------------------------------------- Key: JGRP-1001 URL: https://jira.jboss.org/jira/browse/JGRP-1001 Project: JGroups Issue Type: Task Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.8 Use ByteMan (jboss.org/byteman) to simulate issues that can happen at runtime: do this in unit tests. For example: crash of merge leader after initial round (who frees the locks ?) (same for FLUSH) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 12 months

3
7
0 / 0

[JBoss JIRA] Created: (AS7-1383) Domain Managent - Ensure current authenticated user is associated with current request / thread and is retrievable.

by Darran Lofthouse (JIRA)

Domain Managent - Ensure current authenticated user is associated with current request / thread and is retrievable. ------------------------------------------------------------------------------------------------------------------- Key: AS7-1383 URL: https://issues.jboss.org/browse/AS7-1383 Project: Application Server 7 Issue Type: Task Components: Domain Management, Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 7.1.0.Beta1 Initially for audit but also for other purposes the current user needs to be identifiable for the request being processed. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 12 months

3
4
0 / 0

[JBoss JIRA] Created: (EJBTHREE-2227) @Startup @Singleton (via switchboard) should take into account transitive ENC dependencies before instantiating the bean

by jaikiran pai (JIRA)

@Startup @Singleton (via switchboard) should take into account transitive ENC dependencies before instantiating the bean ------------------------------------------------------------------------------------------------------------------------ Key: EJBTHREE-2227 URL: https://issues.jboss.org/browse/EJBTHREE-2227 Project: EJB 3.0 Issue Type: Bug Components: singleton Affects Versions: depchain-1.0.0-alpha-43 Environment: JBoss AS 6.0 Final Reporter: jaikiran pai Assignee: jaikiran pai Consider the following beans: @Startup @Singleton public class A { @EJB private B slsb1; @PostConstruct public void onConstruct() { slsb1.doSomething(); } } @Stateless public class B { @EJB private C slsb2; } @Stateless public class C { .... } Currently, the @Startup @Singleton is instantiated when the ENC of that bean is fully invokable. However, it only waits for a populated ENC of transitive dependent bean(s). This can lead random failures with lookup. Please see the referenced forum thread for the complete details. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

5
11
0 / 0

[JBoss JIRA] Created: (JBAS-8422) Fix build warning for missing pom on ws-commons policy

by Paul Gier (JIRA)

Fix build warning for missing pom on ws-commons policy ------------------------------------------------------ Key: JBAS-8422 URL: https://jira.jboss.org/browse/JBAS-8422 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 6.0.0.M4 Reporter: Paul Gier Priority: Minor The AS 6 trunk build currently gives a warning about the pom missing from ws-commons:policy [WARNING] The POM for ws-commons:policy:jar:1.0 is missing, no dependency information available This is caused by a missing POM file in central http://repo2.maven.org/maven2/ws-commons/policy/1.0/ ws-commons:policy is now called project Neethi. Possible a recent version of Neethi can be used to replace the old policy jar. http://repo2.maven.org/maven2/org/apache/neethi/neethi/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

3
6
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1721) Implement @Asynchronous

by Andrew Lee Rubinger (JIRA)

Implement @Asynchronous ------------------------ Key: EJBTHREE-1721 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1721 Project: EJB 3.0 Issue Type: Task Reporter: Andrew Lee Rubinger Assignee: Andrew Lee Rubinger Fix For: EJB 3.1 Container task for @Asynchronous handling as specified by EJB 3.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

4
5
0 / 0

[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

13 years

9
19
0 / 0

[JBoss JIRA] Created: (JBRULES-3100) Long.MAX_VALUE duration for "A and not(B after A)" type rules causes invalid session clock time in rule RHS when running with pseudo clock

by Richard Calmbach (JIRA)

Long.MAX_VALUE duration for "A and not(B after A)" type rules causes invalid session clock time in rule RHS when running with pseudo clock ------------------------------------------------------------------------------------------------------------------------------------------ Key: JBRULES-3100 URL: https://issues.jboss.org/browse/JBRULES-3100 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core, drools-core (fusion) Affects Versions: 5.2.0.Final Reporter: Richard Calmbach Assignee: Mark Proctor Ok, this is a subtle one. How did I run into this one? I need dynamic timers that are started in the RHS because Drools LHS syntax does not support dynamic timers. In order to be able to unit test my rules even with dynamic timers, I rely on the session clock (aka TimerService) to schedule and execute these manually defined jobs. Works beautifully with the real-time clock for all my rules, and also works with the pseudo clock for rules that don't have a negated unbounded "after" clause. However, the pseudo clock breaks the timers that are scheduled in the RHS of rules that have a LHS of type "A and not(B after A)". The reason is extremely subtle, and understanding it required an excursion into the inner workings of the rule engine, in particular its mechanism for scheduling activations of rules with non-zero duration. (Good thing that javadoc and sources are now available via Maven repositories for all Drools artifacts. Thank you, Drools team and the m2eclipse "Download Artifact Sources" checkbox!) In PseudoClockScheduler.runCallBacks(), the pseudo clock checks whether any scheduled jobs need to be executed by comparing their trigger times to the current time (this.timer). For every job that is due, e.g., a scheduled rule activation, the pseudo clock saves this.timer to a local variable (savedTimer) and sets this.timer temporarily to the trigger time of the job (keeping this.timer at that value for the duration of the job execution, e.g., the firing of the scheduled activation). Now, for rules with a bounded duration (e.g., "A and not(B after[0s, 10s] A"), this trigger time is a reasonable value (current time + duration), and everything works out. However, rules of type "A and not(B after A)" (i.e., with negated unbounded after) have a duration value of Long.MAX_VALUE. When DurationTimer.createTrigger() constructs a new PointInTimeTrigger object, it sets the trigger time to "current time + duration", and with a post-epoch current time (i.e., greater than zero) and duration == Long.MAX_VALUE, this causes wrap-around and sets the trigger time to a very large negative number. Up to this point, I think the behavior of the code is intentional (albeit hacky), to ensure that "negated unbounded after" type rules get activated right away (as they should). However, this approach has unintended, buggy consequences as we shall see. When such a scheduled rule fires, then for the duration of its RHS execution, the session clock has an invalid value (very large negative number). The only way how you would know that is if you queried the session clock, say because you're trying to schedule a dynamic timer because Drools LHS syntax only supports static timers. The upshot is that the dynamic timer job is scheduled with "very large negative number + my trigger delay" as the trigger time, which PseudoClockScheduler.runCallBacks() promptly interprets as a job that is due for execution, causing premature and therefore incorrect triggering of my dynamic timer, thereby breaking my unit tests, while the real-time clock does not exhibit this problem. And that's how I spent my Friday. I can work around this bug by rewriting the "A and not(B after A)" construct so that I'm explicitly comparing the timestamp fields instead of using "after". However, the current Drools implementation is broken in more than one way: Say, you're simulating the events at the original Woodstock (or any other events pre-dating the Unix epoch), and you're setting the pseudo clock to a negative value so that Date.toString() gives you the actual dates of the simulated events. As long as current time is a non-positive value, adding duration == Long.MAX_VALUE will yield a time much, much later than current time. This means that "A and not(B after A)" type rules will not fire when they should because their trigger time is in a future far, far away that will never be reached during the simulation. If I interpret this correctly, this also affects rule activation with the real-time clock if it is set to a negative value (there goes your time traveler market share...). I'm not sure what the best fix for these bugs is. A real fix probably has to rework how "negated unbounded after" type rule activations get scheduled. The duration == Long.MAX_VALUE hack isn't going to cut it. Maybe these rules don't need scheduling at all since their activations should be created right away? Anyway, tricky stuff. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

7
8
0 / 0

[JBoss JIRA] Created: (JBAS-9091) Ensure all domain management modules comply with ANDIAMO-2

by Brian Stansberry (JIRA)

Ensure all domain management modules comply with ANDIAMO-2 ---------------------------------------------------------- Key: JBAS-9091 URL: https://issues.jboss.org/browse/JBAS-9091 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Domain Management Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 7.0.0.Beta4 Use the new logging infrastructure to create internationalized log and exception messages in the core modules. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

5
7
0 / 0

[JBoss JIRA] Created: (JBBUILD-678) Upgrade Nexus to 1.9.1

by Paul Gier (JIRA)

Upgrade Nexus to 1.9.1 ---------------------- Key: JBBUILD-678 URL: https://issues.jboss.org/browse/JBBUILD-678 Project: JBoss Build System Issue Type: Task Reporter: Paul Gier Assignee: Paul Gier Priority: Minor We are experiencing a few bugs in Nexus 1.9.0.2, as described in the build forum. I don't consider these critical, but we should still look into upgrading to 1.9.1 soon after it becomes available. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

5
9
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2011