[JBoss JIRA] Created: (JBRULES-2031) Enhancements to spreadsheet based testing tool
by Michael Neale (JIRA)
Enhancements to spreadsheet based testing tool
----------------------------------------------
Key: JBRULES-2031
URL: https://jira.jboss.org/jira/browse/JBRULES-2031
Project: JBoss Drools
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: drools-testing
Reporter: Michael Neale
Assignee: Michael Neale
Fix For: FUTURE
As mentioned by Ansgar in blog comments: http://blog.athico.com/2009/03/new-testing-tool.html
Hi,
we're using Drools to perform mortgage scoring. For testing, we developed a somewhat similar, but already more sophisticated testing framework. Currently, our test set comprises of roughly 800 test scenarios/test cases.
Similarities:
* also uses spreadsheet tables to define test cases.
* each column resembles a test case
* leftmost column used to name elements of input facts or define expected conditions (see below)
Differences:
* concept of "expected values" not expressed as mere values, but as drools conditions which are expected to hold after rules all under test finished execution. These conditions are automagically converted into a drools query which is run against the working memory after rule execution.
Enhancements:
* conditions support simple text replacement, like a macro preprocessor. Wildcards in drools condition can be replaced by test case-specific text
* allows skipping of certain condition checks on a per-test-case basis
* event logging of the drools working memory embedded into fit output file for failed checks. visibility of log can be toggled using html-embedded javascript. allows for simple copy/paste into "audit view" window in eclipse. This eases debugging rules a lot!
* possibility to define a subset of rules contained in a *.drl file to be tested
Open issues:
* Syntax of initial facts specification is probably a bit cumbersome. We're using a self-brewed language to do this. Already thought of replacing this by MVEL, but not done yet. For us, the current solution works ok.
* Up to now, requires explicit import of all used Java classes. This is rather a limitation of drools - we did not manage to get package imports in *.drl files to work. Could probably be solved.
--
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, 1 month
[JBoss JIRA] Created: (JBAS-9391) EJB3.1 spec 4.8.4: destroying singleton because of error during initialization is not honored
by Pierre Kobylanski (JIRA)
EJB3.1 spec 4.8.4: destroying singleton because of error during initialization is not honored
---------------------------------------------------------------------------------------------
Key: JBAS-9391
URL: https://issues.jboss.org/browse/JBAS-9391
Project: Legacy JBoss Application Server 6
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: EJB
Affects Versions: 6.0.0.Final
Environment: $ uname -a
Linux tumlatum 2.6.38-2-686-bigmem #1 SMP Sun May 8 15:43:39 UTC 2011 i686 GNU/Linux
Reporter: Pierre Kobylanski
Assignee: Carlo de Wolf
ejb 3.1 spec [4.8.4 Singleton Error Handling] says that "Errors occurring during Singleton initialization are considered fatal and must result in the discarding of the Singleton instance."
I tried to raise a system exception in the @PostConstruct method of a singleton bean. Logs show the deployment error. But I then can access and call the singleton methods.
-- Full paragraph 4.8.4: -----------------------------
Errors occurring during Singleton initialization are considered fatal and must result in the discarding of the Singleton instance. Possible initialization errors include injection failure, a system exception thrown from a PostConstruct method, or the failure of a PostConstruct method container-managed transaction to successfully commit. If a singleton fails to initialize, attempted invocations on the Singleton result in an exception as defined by Section 3.4.3 and Section 3.4.4.
------------------------------------------------------
I tested to raise a system exception (throw new RuntimeException()) in the @PostConstruct method.
-- Logs show the error -------------------------------
ERROR [AbstractKernelController] Error installing to Start: name=startup-singleton-initiator:topLevelUnit=ts.ear,unit=testSingletonEjb.jar,bean=counter aliases=[startup-singleton-initiator:bean=counter,topLevelUnit=ts.ear,unit=testSingletonEjb.jar] state=Create: java.lang.RuntimeException: Could not invoke PostConstruct on the newly created bean instance
at org.jboss.ejb3.singleton.impl.container.SingletonEJBInstanceManagerImpl.create(SingletonEJBInstanceManagerImpl.java:137) [:1.0.0-alpha-28]
...
Caused by: testsingleton.exn.SE // class SE extends RuntimeException{}
at testsingleton.ejb.CounterEjb.pc(CounterEjb.java:28)
DEPLOYMENTS IN ERROR:
Deployment "startup-singleton-initiator:topLevelUnit=ts.ear,unit=testSingletonEjb.jar,bean=counter" is in error due to the following reason(s): testsingleton.exn.SE
at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:1228) [:2.2.0.GA]
------------------------------------------------------
However, it is after that possible to access the singleton through a JNDI lookup and successfully call its methods.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] Created: (EJBTHREE-1642) The <security-domain> tag included in <container-configuration> in the jboss.xml file is ignored
by John Gonon (JIRA)
The <security-domain> tag included in <container-configuration> in the jboss.xml file is ignored
------------------------------------------------------------------------------------------------
Key: EJBTHREE-1642
URL: https://jira.jboss.org/jira/browse/EJBTHREE-1642
Project: EJB 3.0
Issue Type: Bug
Components: Security
Affects Versions: HEAD
Environment: Windows XP
JDK 1.6.build10
JBOSS 5.0.0.GA
Reporter: John Gonon
Priority: Minor
The <security-domain> tag included in <container-configuration> in the jboss.xml file is ignored.
I have tracked were the problem seems to be (at least as I saw it).
In the class "org.jboss.ejb3.security.bridge.SecurityDomainMetaDataBridge" there are those lines:
//TODO: How to get the merged meta data? Is the following line correct?
if(securityDomain == null)
securityDomain = beanMetaData.getJBossMetaData().getSecurityDomain();
I replaced them with:
if (securityDomain == null) {
JBossMetaData metaData = beanMetaData.getJBossMetaData();
securityDomain = metaData.getContainerConfiguration(beanMetaData.determineConfigurationName())
.getSecurityDomain();
if (securityDomain == null)
securityDomain = metaData.getSecurityDomain();
}
As I understand it, if no "SecurityDomain" annotation is found, then we finish in this class and we do in order:
1. seek for a security domain in the bean's metadata (I guess it is in the EJB declaration)
2. seek for the one in "jboss-app.xml"
I inserted between them some code returning the one comming from the container's configuration
I hope this helps ...
Best regards,
Please keep me informed,
I hope to remove my "modified" jar with an official one soon.
John
--
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, 1 month
[JBoss JIRA] Created: (JBAS-6326) InterruptedException on shutdown
by Jeff Yu (JIRA)
InterruptedException on shutdown
--------------------------------
Key: JBAS-6326
URL: https://jira.jboss.org/jira/browse/JBAS-6326
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JCA service
Affects Versions: JBossAS-4.2.2.GA
Reporter: Jeff Yu
Assignee: Jeff Zhang
Priority: Minor
I see the following exception on shutdown with either default, all, production servers (using all's log4j configuration). I'm not sure it is necessary for users to see. Probably needs to be changed to DEBUG level if really not relevant.
09:07:59,647 WARN [NewMsgsWorker] Interrupted waiting for new msg check
java.lang.InterruptedException
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:474)
at EDU.oswego.cs.dl.util.concurrent.Semaphore.acquire(Semaphore.java:108)
at EDU.oswego.cs.dl.util.concurrent.SemaphoreControlledChannel.take(SemaphoreControlledChannel.java:131)
at org.jboss.resource.adapter.mail.inflow.NewMsgsWorker.run(NewMsgsWorker.java:75)
at org.jboss.resource.work.WorkWrapper.execute(WorkWrapper.java:204)
at org.jboss.util.threadpool.BasicTaskWrapper.run(BasicTaskWrapper.java:275)
at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:756)
at java.lang.Thread.run(Thread.java:595)
--
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, 1 month
[JBoss JIRA] Created: (AS7-777) Switchable Nonce Handling Strategy for HTTP DigestAuthenticator
by Darran Lofthouse (JIRA)
Switchable Nonce Handling Strategy for HTTP DigestAuthenticator
---------------------------------------------------------------
Key: AS7-777
URL: https://issues.jboss.org/browse/AS7-777
Project: Application Server 7
Issue Type: Task
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 7.0.0.CR1
Allow the nonce strategy to be switchable: -
1 - Real 'Number Used Once' - i.e. new nonce for each request.
2 - Nonce per connection i.e. as long as a connection is kept alive allow re-use of nonce - new nonce on new connection.
3 - Timed nonce - Generate a nonce with a server secret and timestamp, nonce will be accepted for a validity period.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month