April 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-8959) JPA 2.0 implementation

by Scott Marlow (JIRA)

JPA 2.0 implementation ---------------------- Key: JBAS-8959 URL: https://issues.jboss.org/browse/JBAS-8959 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Reporter: Scott Marlow Assignee: Scott Marlow -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 2 months

1
6
0 / 0

[JBoss JIRA] Created: (JBAS-8895) Can't connect to JMS before server has started up completely

by Jack van Ooststroom (JIRA)

Can't connect to JMS before server has started up completely ------------------------------------------------------------ Key: JBAS-8895 URL: https://issues.jboss.org/browse/JBAS-8895 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JMS (HornetQ) Affects Versions: 6.0.0.Final Environment: JBoss 6.0.0.Final with HornetQ configured Reporter: Jack van Ooststroom Attachments: jmstest.war It seems that with JBoss AS 6.0.0.Final I can't connect to JMS before the application server itself has started up completely. I'm using the InitialContext approach as I can't use Message Driven Beans in the project. I created a JMS Topic in [jboss-home]/server/default/deploy/hornetq/hornetq-jms.xml as follows: <topic name="MyTopic"> <entry name="/topic/test"/> </topic> Next I'm trying to connect to JMS from my JMSServlet's init(ServletConfig) method, but that seems to fail when executing the JMS detection on the original thread (that is the thread supplied by the application server) as follows: Unable to validate user: null for check type CREATE_NON_DURABLE_QUEUE for address jms.topic.MyTopic I'd prefer not having to specify the user/password, but even if I do it fails in a similar fashion: Unable to validate user: guest for check type CREATE_NON_DURABLE_QUEUE for address jms.topic.MyTopic When I do the detection of JMS on a seperate thread it eventually seems to work, as long as the application server started up completely. However, timing is then a bit undeterministic. When running this test on earlier versions of JBoss AS, namely 5 and 4, or other application servers the detection seems to succeed on the first try on the original thread. Why does JBoss AS 6.0.0.Final behave differently? Is there some configuration I am missing? Is this a potential bug? I'll attach my JMS Test application which tries to connect to JMS using 6 different strategies: * On original thread * On original thread after sleep * On spawned thread with await/signal * On spawned thread with await/signal after sleep * On spawned thread without await/signal * On spawned thread without await/signal after sleep The source is included in the jmstest.war file. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 2 months

9
33
0 / 0

[JBoss JIRA] Created: (JGRP-955) AckSenderWindow: use ConcurrentSkipListMap instead of ConcurrentHashMap

by Bela Ban (JIRA)

AckSenderWindow: use ConcurrentSkipListMap instead of ConcurrentHashMap ----------------------------------------------------------------------- Key: JGRP-955 URL: https://jira.jboss.org/jira/browse/JGRP-955 Project: JGroups Issue Type: Task Reporter: Bela Ban Assignee: Bela Ban Priority: Minor Fix For: 3.0 So we have the seqnos sorted, and can implement ack(seqno) as a headSet(seqno).clear(). -- 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

15 years, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (JGRP-1141) RspList: use generics

by Bela Ban (JIRA)

RspList: use generics --------------------- Key: JGRP-1141 URL: https://jira.jboss.org/jira/browse/JGRP-1141 Project: JGroups Issue Type: Task Reporter: Bela Ban Assignee: Bela Ban Priority: Minor Fix For: 3.0 e.g. RspList<Integer> list=disp.callRemoteMethods(....); for(Rsp<Ineteger> rsp: rsps) { int counter=rsp.getValue(); } -- 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

15 years, 2 months

1
7
0 / 0

[JBoss JIRA] Created: (JGRP-403) Refactoring of MessageDispatcher, RpcDispatcher, RequestCorrelator and GroupRequest

by Bela Ban (JIRA)

Refactoring of MessageDispatcher, RpcDispatcher, RequestCorrelator and GroupRequest ----------------------------------------------------------------------------------- Key: JGRP-403 URL: http://jira.jboss.com/jira/browse/JGRP-403 Project: JGroups Issue Type: Task Affects Versions: 2.4 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 3.0 We may be able to trash GroupRequest and RequestCorrelator, this functionality can be provided by MessageDispatcher -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 2 months

2
1
0 / 0

[JBoss JIRA] Created: (JGRP-1056) RpcDispatcher: reduce number of callXXX() methods

by Bela Ban (JIRA)

RpcDispatcher: reduce number of callXXX() methods ------------------------------------------------- Key: JGRP-1056 URL: https://jira.jboss.org/jira/browse/JGRP-1056 Project: JGroups Issue Type: Task Reporter: Bela Ban Assignee: Bela Ban Fix For: 3.0 Instead, create methods callRemoteMethod(Collection<Address> dests, MethodCall call) and callRemoteMethod(Address dest, MethodCall call); MethodCall then contains all necessary details for invoking the clustered call, e.g. - method name, types of parameters and actual argument (already exists, and is marshalled) - mode (GET_FIRST, GET_ALL etc) - timeout - Flags (e.g. OOB, DONT_BUNDLE) - boolean use_anycasts - RspFilter -- 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

15 years, 2 months

1
2
0 / 0

[JBoss JIRA] Created: (JBRULES-2211) StatefulKnowledgeSession leaves threads running

by Edson Tirelli (JIRA)

StatefulKnowledgeSession leaves threads running ----------------------------------------------- Key: JBRULES-2211 URL: https://jira.jboss.org/jira/browse/JBRULES-2211 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core Affects Versions: 5.0.1.FINAL, 5.0.0.FINAL Reporter: Edson Tirelli Assignee: Edson Tirelli Fix For: 5.1.0.M1 Hi all, I've downloaded Drools fusion sample and started to make some changes to the code (first of all wipe out the UI so I can test it easier). I tried to get to a minimal set so I can run a console main class and see what happens but I am facing a strange behaviour. As soon as I start pushing events into the WorkingMemoryEntryPoint ("StockTick stream") a Thread - not daemonized since it blocks shutdown from ending - is spawned and this prevents my JVM from shutting down (obviously if I call System.exit(0) it will but I am avoiding this). I've tried both to halt and dispose the session that this entry point belongs but with no success. Does anyone know how could I get rid of this thread? ================== Hi Edson! as I've already mentioned I've modified the sample so, if you get the StockTick sample and replace the Main class this will run fine. The sample shuts down fine but as I saw it sets the JFrame uses frame.setDefaultCloseOperation( WindowConstants.EXIT_ON_CLOSE ); which in turn makes the trick. Below the code of my modified main class: package org.drools.examples.broker; import org.drools.KnowledgeBase; import org.drools.KnowledgeBaseConfiguration; import org.drools.KnowledgeBaseFactory; import org.drools.builder.KnowledgeBuilder; import org.drools.builder.KnowledgeBuilderFactory; import org.drools.builder.ResourceType; import org.drools.conf.EventProcessingOption; import org.drools.examples.broker.model.Company; import org.drools.examples.broker.model.CompanyRegistry; import org.drools.examples.broker.model.StockTick; import org.drools.io.ResourceFactory; import org.drools.runtime.StatefulKnowledgeSession; import org.drools.runtime.rule.WorkingMemoryEntryPoint; public class Main { private static final String RULES_FILE = "/broker.drl"; static StatefulKnowledgeSession session; static WorkingMemoryEntryPoint tickStream; /** * @param args */ public static void main(String[] args) throws Exception { // set up and show main window CompanyRegistry companies = new CompanyRegistry(); KnowledgeBuilder builder = KnowledgeBuilderFactory.newKnowledgeBuilder(); try { builder.add( ResourceFactory.newInputStreamResource( Main.class.getResourceAsStream( RULES_FILE ) ), ResourceType.DRL); } catch ( Exception e ) { e.printStackTrace(); } if( builder.hasErrors() ) { System.err.println(builder.getErrors()); System.exit( 0 ); } KnowledgeBaseConfiguration conf = KnowledgeBaseFactory.newKnowledgeBaseConfiguration(); conf.setOption( EventProcessingOption.STREAM ); KnowledgeBase kbase = KnowledgeBaseFactory.newKnowledgeBase( conf ); kbase.addKnowledgePackages( builder.getKnowledgePackages() ); session = kbase.newStatefulKnowledgeSession(); session.setGlobal( "services", new BrokerServices() { public void log(String message) { System.out.println(message); } }); for( Company company : companies.getCompanies() ) { session.insert( company ); } session.fireAllRules(); tickStream = session.getWorkingMemoryEntryPoint( "StockTick stream" ); for (int i=10;i>0;i--) { tickStream.insert(new StockTick("RHT", i*10, System.currentTimeMillis())); session.getAgenda().getAgendaGroup( "evaluation" ).setFocus(); session.fireAllRules(); } session.dispose(); session.halt(); System.out.println("Still running..."); } } regards, Rafael Ribeiro -- 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

15 years, 2 months

3
8
0 / 0

[JBoss JIRA] Created: (JBRULES-2862) fusion not evicting events from memory when it should

by Radai Rosenblatt (JIRA)

fusion not evicting events from memory when it should ----------------------------------------------------- Key: JBRULES-2862 URL: https://issues.jboss.org/browse/JBRULES-2862 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core (fusion) Affects Versions: 5.1.1.FINAL Environment: windows xp, JDK 6u21 Reporter: Radai Rosenblatt Assignee: Mark Proctor using the following declaration: declare Event @role( event ) @duration ( duration ) @timestamp( finished ) end when writing the following rule: rule "Match Any Two Events In Window" when $eventOne : Event() over window:time( 3d ) from entry-point "Event Stream" $eventTwo : Event() over window:time( 3d ) from entry-point "Event Stream" then //nothing end and simulating a long run (longer than 3 days), old events (older than 3 days) are not evicted from memory. however, dropping the $eventTwo line entirely evicts events from memory properly -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 2 months

3
11
0 / 0

[JBoss JIRA] Created: (JBRULES-2881) sliding window:length(1) sticks to old event

by Wolfgang Laun (JIRA)

sliding window:length(1) sticks to old event -------------------------------------------- Key: JBRULES-2881 URL: https://issues.jboss.org/browse/JBRULES-2881 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core Affects Versions: 5.1.1.FINAL Reporter: Wolfgang Laun Assignee: Mark Proctor A rule combining two events of type A and B, each "seen" through a sliding window of length 1 misfires. Rather that combining the latest A with the latest B, it keeps firing the latest B together with *all* old A's. Interestingly, this effect disappears if the order of patterns in the rule is inverted. Given the event sequence: A, A, B, A, B, the rule ab when A() over window:length(1) B() over window:length(1) then ... end misfires, but rule ba when B() over window:length(1) A() over window:length(1) then ... end works correctly. This may be related to JBRULES-2862. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 2 months

3
6
0 / 0

[JBoss JIRA] Created: (JBAS-9347) Create a "jboss-welcome.war" greeting page application

by David Lloyd (JIRA)

Create a "jboss-welcome.war" greeting page application ------------------------------------------------------ Key: JBAS-9347 URL: https://issues.jboss.org/browse/JBAS-9347 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Reporter: David Lloyd Fix For: 7.0.0.CR1 The application should create a /index.html page in the root of the web server, and should contain a greeting message with some getting-started instructions and useful links. It should include instructions for how to remove the application from the configuration, and possibly even some functionality to carry that out. It should work in both domain and standalone mode and it should be referenced from the configuration as a filesystem-backed deployment, not as managed content or as a hot deployment. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 2 months

4
4
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2011