[JBoss JIRA] Created: (JBESB-1952) update readme.txt in samples/quickstarts/helloworld_action/oracle-aq
by Mike T. (JIRA)
update readme.txt in samples/quickstarts/helloworld_action/oracle-aq
--------------------------------------------------------------------
Key: JBESB-1952
URL: https://jira.jboss.org/jira/browse/JBESB-1952
Project: JBoss ESB
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Examples
Environment: This has been found in JBoss ESB 4.3. Very possible that newer versions have the same issue.
Reporter: Mike T.
the readme.txt file located in samples\quickstarts\helloworld_action\oracle-aq which includes instructions on setting up Oracle AQ as a JMS provider needs to be updated:
- jndi.properties file does not need to be edited as per step 2. jboss-esb.xml needs to be edited.
- lib/ext/jms/oracleaq folder does not exist in the distribution. It would recommended to include them or include links to where they can be downloaded from.
--
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
16 years, 4 months
[JBoss JIRA] Created: (JBESB-1166) ESB Message Property setter/getter shortcut
by Burr Sutter (JIRA)
ESB Message Property setter/getter shortcut
-------------------------------------------
Key: JBESB-1166
URL: http://jira.jboss.com/jira/browse/JBESB-1166
Project: JBoss ESB
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Rosetta
Affects Versions: 4.2.1 IR1
Reporter: Burr Sutter
Assigned To: Mark Little
Fix For: 4.2.1
I have noticed that in my code I have a lot of this kind of usage for the properties on the esb message object:
esbMessage.getProperties().setProperty("MAIL_SUBJECT",subject);
esbMessage.getProperties().setProperty("MAIL_MESSAGE_NUMBER",mailMessage.getMessageNumber());
esbMessage.getProperties().setProperty("MAIL_SENT_DATE",mailMessage.getSentDate());
I propose we create "shortcut" methods on the Message class itself like so:
esbMessage.setProperty("MAIL_SUBJECT",subject);
esbMessage.setProperty("MAIL_MESSAGE_NUMBER",mailMessage.getMessageNumber());
esbMessage.setProperty("MAIL_SENT_DATE",mailMessage.getSentDate());
The use of the word "property" in the setter/getter should make it obvious what part of the message it is going into. We should also consider the same for header, attachment, etc.
--
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
16 years, 4 months
[JBoss JIRA] Created: (JBESB-1944) The InVM courier is not completely valid from concurrency point of view
by Jiri Pechanec (JIRA)
The InVM courier is not completely valid from concurrency point of view
-----------------------------------------------------------------------
Key: JBESB-1944
URL: https://jira.jboss.org/jira/browse/JBESB-1944
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Rosetta, Transports
Affects Versions: 4.4
Reporter: Jiri Pechanec
Fix For: 4.4 CP1
There are few problems with current implementation of InVM courier.
1) The message queue uses ConcurrentLinkedQueue as backing data structure. Unfortunately the synchronized primitive is used as lock on this queue whicm means that all advanatages of using it are negated. I guess that this approch is used for lockstep. The correct soultion is should be to have messageQueue unsychchronized and have separate Event object or separate regular object as lock holder if lockstep is in place.
2) The lockstep does not work correctly when there are multiple threads on input/output of the queue. The notify call does not guarantee that the correct delivery/pickup threads are waken up. For example the notify call in one delivery thread can wake up another delivery thread waiting up for the notify from pickup thread.
--
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
16 years, 4 months
[JBoss JIRA] Created: (JBESB-1918) Implementation of ScriptingAction is inefficient and incomplete
by Jiri Pechanec (JIRA)
Implementation of ScriptingAction is inefficient and incomplete
---------------------------------------------------------------
Key: JBESB-1918
URL: https://jira.jboss.org/jira/browse/JBESB-1918
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Rosetta
Affects Versions: 4.4
Reporter: Jiri Pechanec
Fix For: 4.2.1 CP4
The ScriptingAction should be polished for beter perfromance and functionality as Groovy scripting action
- BSFManager should be created in intialize(), not process() method (credit goes to Kevin :-))
- The script reload should be supported
- Is it necessary to process BSF config file? Cannot we use getLangFromFilename method?
- It should be probably stated in the docs that for compiled scriping languages it is not guranteed that the compliation is done only once which can lead to performance degradation - native action can be preferred in such case
--
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
16 years, 4 months
[JBoss JIRA] Created: (JBESB-1966) EsbActionHandler cannot put property value of an object in jBPM scope to ESB message
by Jacky Cheung (JIRA)
EsbActionHandler cannot put property value of an object in jBPM scope to ESB message
------------------------------------------------------------------------------------
Key: JBESB-1966
URL: https://jira.jboss.org/jira/browse/JBESB-1966
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 4.4, 4.3
Reporter: Jacky Cheung
I am developing application on JBossESB with jBPM as the workflow engine.
In my process definition (jpdl), I have the following node:
<node name="retrieve record">
<action name="fetch record" class="org.jboss.soa.esb.services.jbpm.actionhandlers.EsbActionHandler">
<esbCategoryName>Test</esbCategoryName>
<esbServiceName>TestService</esbServiceName>
<bpmToEsbVars>
<mapping bpm="request.studentName" esb="studentName"/>
</bpmToEsbVars>
<esbToBpmVars>
<mapping esb="status"/>
</esbToBpmVars>
</action>
<transition name="ok" to="decide notify parent"/>
</node>
I got the following exception when jBPM transits into the node
Caused by: org.mvel.PropertyAccessException: unable to resolve property: request
at org.mvel.optimizers.impl.refl.ReflectiveAccessorOptimizer.getBeanProperty(ReflectiveAccessorOptimizer.java:374)
After debuging, I discover JBpmObjectMapper has a bug that breaks the feature.
Line 157 of the class (in JBossESB 4.3) is
objectName = expression.substring(0, dotPosition-1);
In my example, the content of expression variable will be "request.studentName" and the objectName will be "reques". This is wrong. The expected one should be "request".
The fix to this bug is simple. Just remove "-1" from the line so that the line should read as...
objectName = expression.substring(0, dotPosition);
I checked EsbNotifier and I found it call the same class. That means this bug will affect EsbNotifier as well.
At the moment, I can change the bpm attribute to "processInstance.contextInstance.variables.request.studentName" to workaround the bug but my XML becomes difficult to read.
I also breaks in JBossESB 4.4.
The fix is very simple but critical (from my point of view).
--
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
16 years, 4 months
[JBoss JIRA] Created: (JBESB-1956) run.bat has lost its permgen setting
by Burr Sutter (JIRA)
run.bat has lost its permgen setting
------------------------------------
Key: JBESB-1956
URL: https://jira.jboss.org/jira/browse/JBESB-1956
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Configuration
Affects Versions: 4.4
Reporter: Burr Sutter
Priority: Critical
Fix For: 4.4 CP1
The permgen setting for run.bat (on windows) has gone missing in the JBESB_4_4_GA_CP branch. It has historically been set as follows:
set JAVA_OPTS=%JAVA_OPTS% -Xms128m -Xmx728m -XX:PermSize=256m -XX:MaxPermSize=512m
The reason for this change is the vast amount of Hibernate class generation/schema generation that is going on while deploying jBPM.
It is also missing from trunk as well and appears to be due to a change in product\install\jbossesb-server-base.zip which included a new run.bat which needs to be tweaked.
--
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
16 years, 4 months