[JBoss JIRA] Created: (JBRULES-1619) Creating a Business rule (using guided editor) which contains a variable which is very long breaks the GUI so you cannot add any more conditions or actions.
by Richard Ambridge (JIRA)
Creating a Business rule (using guided editor) which contains a variable which is very long breaks the GUI so you cannot add any more conditions or actions.
------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: JBRULES-1619
URL: http://jira.jboss.com/jira/browse/JBRULES-1619
Project: JBoss Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-brms
Affects Versions: 4.0.7
Environment: Solaris 10, firefox, glassfish
Reporter: Richard Ambridge
Assigned To: Mark Proctor
Creating a Business rule (using guided editor) which contains a variable which is very long breaks the GUI so you cannot add any more conditions or actions.
First create a DSL,
[when]Condition sentence template {var}=rule language mapping {var}
[then]Action{var}e=rule language mapping {var}
[then]action2=test
next create a Business rule (using guided editor)
click on the When +
add the 'Condition sentence template {var}'
edit the variable var and set it to 1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1
click on the Then +
select 'Action'
edit the var for Action and set it to anything
Now, notice the screen has redrawn and all the 1.1.1. has push everything off the edge of the screen.
Now you wish to add another Then +
scroll your wish to the Then +
Clicking on the Then + results in the popup being off screen, and you can never get to it...
--
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, 11 months
[JBoss JIRA] Created: (JBMESSAGING-1294) Limit core sessions to also transacted for acks
by Tim Fox (JIRA)
Limit core sessions to also transacted for acks
-----------------------------------------------
Key: JBMESSAGING-1294
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1294
Project: JBoss Messaging
Issue Type: Task
Reporter: Tim Fox
Assigned To: Tim Fox
Fix For: 2.0.0 Beta
Currently core sessions have a batch size and can be set to auto commit acks. These is fairly complex and makes it hard to apply
JMS message listener redelivery semantics.
With a JMS message listener auto_ack or dups_ok, if a runtimeexception is thrown from onMessage the last message should be redelivered.
An auto_ack session is marked as auto commit acks, so if we immediately rollback when receiving the exception, the last message is acked so is not redelivered.
Solution here is never to auto commit acks. Sessions are always transacted (sends can be auto_acked or have concurrency problems when concurrently receiving and sending messages in a dups_ok session), and acks must be explicitly acked anc committed by the JMS layer.
This should simplify the code too.
Uncomment MessageConsumerTest::testExceptionMessageListener1 and 2 when this is complete
--
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, 11 months
[JBoss JIRA] Created: (JBAS-5646) @EJB does not work in servlet
by Rick Vederman (JIRA)
@EJB does not work in servlet
-----------------------------
Key: JBAS-5646
URL: http://jira.jboss.com/jira/browse/JBAS-5646
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: JBossAS-5.0.0.CR1
Environment: JBOSS trunk revision 74818 on both Windows 2000SP4 and Linux Fedora 8 (64-bit) with 32-bit JDK 1.5.0.14 (on both Windows and Linux)
Reporter: Rick Vederman
This was not an issue in 5.0.0.Beta4. I pulled the trunk to get the fix for another bug and this cropped up. Basically, I declare an interface POJO and prefix it with @Remote. I then declare a stateless EJB which implements that interface and prefix it with @Stateless. Finally, I create a servlet and prefix an attribute declaration of the interface type using @EJB. None of the annotations have any parameters.
See the Forum reference for the log dump (first post) as well as the java code (third post). I apologize if this is a duplicate...I see some other issues which look close, but I was not sure.
Work-around:
Add 'mappedName="EJB3Test1/CoverageWCBean/remote"' to the @EJB annotation in the servlet. This gets me past the "java.lang.IllegalStateException: Resolution should not happen via injection container" problem, but then this problem crops up:
23:41:28,159 ERROR [FieldBeanProperty] failed to set value jboss.j2ee:ear=EJB3Test.ear,jar=EJB3TestEJB.jar,name=CoverageWCBean,service=EJB3 on field private ic.poc.wc.CoverageWC EJB3TestServlet.wc
java.lang.IllegalArgumentException
at sun.reflect.UnsafeObjectFieldAccessorImpl.set(UnsafeObjectFieldAccessorImpl.java:63)
This problem is then worked around by setting CallByValue=true in the Naming service (jboss-service.xml) and then it works (EJBTHREE-983 might be related to this problem). Note that I tested this in GlassFish and it all works fine with just the annotations without any parameters as it did under 5.0.0.Beta4.
--
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, 11 months