[JBoss JIRA] Created: (JBESB-570) Configuration of JBoss AS installation directory in deployment.properties for ESB trailblazers fails if a relative path is used or the path name contains spaces
by Pete Bennett (JIRA)
Configuration of JBoss AS installation directory in deployment.properties for ESB trailblazers fails if a relative path is used or the path name contains spaces
----------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: JBESB-570
URL: http://jira.jboss.com/jira/browse/JBESB-570
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Configuration
Affects Versions: 4.2 Milestone Release 2
Environment: Fedora Core 6
J2SE 5
Ant 1.6.5
Reporter: Pete Bennett
Assigned To: Mark Little
Priority: Minor
In the Quickstart guide and the Trailblazers, one needs to configure the deployment.properties file to point at an installation of JBoss AS with EJB3 enabled.
If the path specified includes a space then things will seem to work, but when you try to start up the JBoss AS server for the Quickstart example, you get an error in the JBoss AS console Window when the ESB service tries to parse this pass as follows:
11:14:06,973 INFO [DatabaseInitializer] Initializing java:/juddiDB from listed sql files
11:14:07,166 INFO [JuddiRMIService] starting juddi RMI service
11:14:07,171 WARN [ServiceController] Problem starting service jboss.esb:service=JuddiRMI
java.net.URISyntaxException: Illegal character in path at index 31: file:/home/pbennett/JBoss/JBoss ESB/4.2MR2/jbossesb-server/server/default/deploy/jbossesb.sar/esb.juddi.properties
at java.net.URI$Parser.fail(URI.java:2816)
at java.net.URI$Parser.checkChars(URI.java:2989)
at java.net.URI$Parser.parseHierarchical(URI.java:3073)
at java.net.URI$Parser.parse(URI.java:3021)
at java.net.URI.<init>(URI.java:578)
at org.jboss.internal.soa.esb.dependencies.JuddiRMIService.startService(JuddiRMIService.java:63)
...
If you use a relative path rather than an absolute path, then the Quickstart example works when run from the original directory but the other Trailblazer examples fail to find the correct directory as they look relative to themselves rather than relative to the root.
--
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, 5 months
[JBoss JIRA] Created: (JBESB-467) Reducing registry lookup overhead
by Mark Little (JIRA)
Reducing registry lookup overhead
---------------------------------
Key: JBESB-467
URL: http://jira.jboss.com/jira/browse/JBESB-467
Project: JBoss ESB
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Registry and Repository, Rosetta
Affects Versions: 4.0
Reporter: Mark Little
Assigned To: Kurt Stam
Priority: Critical
Fix For: 4.2, 5.0
>From our previous discussion on reducing registry lookup overhead (currently lookup per message send):
There are a number of solutions to this and we should try to support them all eventually:
(i) EPR lifetime: service deployers can register a lifetime associated with the EPR in the registry and when something reads the EPR it also receives information on how long the EPR will remain valid for. After that time elapses, clients must go back to the registry to get a new copy.
(ii) building on (i), EPRs can be marked as persistent - they never change so one lookup will always be enough.
(iii) interactions with services are scoped by sessions and the EPR is assumed to remain valid for the duration of the session. The service can be marked as useable within such a session.
(iv) EPRs are looked up once per client lifecycle and only rebound if the service fails. If you recall from the original ESB architecture document, service migration is something that is on the roadmap (5.0) and if a service moves it can leave a forwarding address (EPR) and the architecture allows messages to be redirected and eventually short-cut, i.e., the client EPR is updated with the new EPR transparently as a result of receiving a response from a different endpoint.
(iii) and (iv) are really for the 5.0 architecture. However, it should be possible to add something along (i) and (ii) for 4.0. What do you think?
--
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, 5 months
[JBoss JIRA] Created: (JBESB-643) Add BRMS support to RuleService
by Jeff DeLong (JIRA)
Add BRMS support to RuleService
--------------------------------
Key: JBESB-643
URL: http://jira.jboss.com/jira/browse/JBESB-643
Project: JBoss ESB
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Content Based Routing
Reporter: Jeff DeLong
Assigned To: Mark Little
Add BRMS support to the platform. In particular the capability to specify a rulesBase in the ruleService configuration and have the ruleService retrieve the ruleBase from the BRMS instead of creating ruleBase on the fly from drl / dsl files on the classpath. This will allow for better maintenance and management of the rules, as well as "hot" deployment on the rules.
Note - I listed this under CBR as there is not a RuleService Component listed, however it applies to both CBR and RuleService.
--
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, 6 months