[JBoss JIRA] Created: (JBESB-476) Make action, listener etc configuration setting by setter method the default
by Tom Fennelly (JIRA)
Make action, listener etc configuration setting by setter method the default
----------------------------------------------------------------------------
Key: JBESB-476
URL: http://jira.jboss.com/jira/browse/JBESB-476
Project: JBoss ESB
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: 4.0
Reporter: Tom Fennelly
Assigned To: Mark Little
Fix For: 4.2
We currently configure everything by constructor. This is not great for a number of reasons:
1. It can't be compile time validated.
2. Not as "obvious" to someone developing against the API. If in an interface, their IDE (or at least compiler - if using a stone ax) will complain immediately that they're not implementing the interface correctly.
3. Makes our code a little bit more complicated re the reflection code that needs to be implemented.
So I suggest making the interface (that all these things implement) contain a setter method that takes the config. The mandate on the implementation is that they contain a public default constructor.
--
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
13 years, 11 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
15 years, 9 months
[JBoss JIRA] Created: (JBESB-459) Create a message validation cartridge that can be used by Smooks to perform message validation.
by Tom Fennelly (JIRA)
Create a message validation cartridge that can be used by Smooks to perform message validation.
-----------------------------------------------------------------------------------------------
Key: JBESB-459
URL: http://jira.jboss.com/jira/browse/JBESB-459
Project: JBoss ESB
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: 4.0
Reporter: Tom Fennelly
Assigned To: Mark Little
Priority: Optional
Fix For: 4.2
Something as simple as cartridge that would allow you target and apply regexp and XPath expressions at parts of a message, generating error/warning reports. I actually used Smooks to prototyped something that's conceptually similar from a validation perspective - analyze a website using Smooks, and generate a report contain possible browser issues with each page (message) e.g. on browser "X" on Mac Os X, this part of the markup may cause usability issues etc (http://milyn.codehaus.org/Smooks+Report+Generator).
The cartridge could allow you create "validation" resources that can be targeted at message exchanges (fragments, elements, attributes etc). This might support applying regexp expressions to data values (match, not-match etc - easy enough) as well as using xpath (has-child-element etc easy enough too *I think*). Would obviously get more difficult if you started to add some form of expression language to it - "if attribute matches X and doesn't have child element Y" etc.
Might be possible to use JBoss Rules and some form of DSL to wrap the xpath stuff (or even the regex stuff too).
--
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, 10 months
[JBoss JIRA] Created: (JBESB-452) Refactor Notifiers
by Kurt Stam (JIRA)
Refactor Notifiers
------------------
Key: JBESB-452
URL: http://jira.jboss.com/jira/browse/JBESB-452
Project: JBoss ESB
Issue Type: Task
Security Level: Public (Everyone can see)
Affects Versions: 4.0
Environment: any
Reporter: Kurt Stam
Assigned To: Mark Little
Priority: Critical
Fix For: 4.2
These comments are based on the JMS notifiers but will probably apply to the other notifiers as well:
1. The notifiers should be more like listeners where you get one (or more instances). Until they get recycled when there is a config change. Right now the JMS onces
connected and disconnect with every message, which causes stress on the JMS provider when running in high load mode.
2. They should get their 'provider' configuration from the configuration, just like the listeners. Right now you cannot connect to other JMS providers.
3. The notifiers should get hooked up to the same life cycle management as the listener infrastructure.
In other words: They really should be 'inverse gateways', the model is broken and there shouldn't be a distinction between notifying and sending a message via couriers+listeners. The fact we support different transports (and in different ways) for notifiers than for the "core" ESB is just wrong.
--
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, 9 months
[JBoss JIRA] Created: (JBESB-479) deploying queues in esb archive does not work in scoped JBM deployments
by Kurt Stam (JIRA)
deploying queues in esb archive does not work in scoped JBM deployments
-----------------------------------------------------------------------
Key: JBESB-479
URL: http://jira.jboss.com/jira/browse/JBESB-479
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Environment: JBossAS4.0.5 with JBM in a scoped sar.
Reporter: Kurt Stam
Assigned To: Mark Little
When deploying a queue-service.xml (with or without) scoping information on JBM in a scoped sar (Needed in the full JBossAS environment) the deployment fails, see the stacktrace below.
Note that this works fine in the standalone jbossesb-server where JBM is deployed in an Unscoped sar.
2007-03-20 09:29:40,953 DEBUG [org.jboss.system.ServiceController] starting service jboss.messaging.destination:service=Queue,name=quickstart_helloworld_Request
2007-03-20 09:29:40,953 DEBUG [org.jboss.jms.server.destination.QueueService] Starting jboss.messaging.destination:service=Queue,name=quickstart_helloworld_Request
2007-03-20 09:29:40,953 ERROR [org.jboss.jms.util.ExceptionUtil] Queue[(destination.getName() == NULL)] startService
java.lang.ClassCastException: org.jboss.jms.server.ServerPeer
at org.jboss.jms.server.destination.DestinationServiceSupport.startService(DestinationServiceSupport.java:107)
at org.jboss.jms.server.destination.QueueService.startService(QueueService.java:63)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:196)
at sun.reflect.GeneratedMethodAccessor69.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:995)
at $Proxy0.start(Unknown Source)
at org.jboss.system.ServiceController.start(ServiceController.java:417)
at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy4.start(Unknown Source)
at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1015)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
at sun.reflect.GeneratedMethodAccessor20.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy8.deploy(Unknown Source)
at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
at $Proxy0.start(Unknown Source)
at org.jboss.system.ServiceController.start(ServiceController.java:417)
at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy4.start(Unknown Source)
at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy5.deploy(Unknown Source)
at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
at org.jboss.Main.boot(Main.java:200)
at org.jboss.Main$1.run(Main.java:490)
at java.lang.Thread.run(Thread.java:595)
2007-03-20 09:29:41,000 DEBUG [org.jboss.jms.server.destination.QueueService] Starting failed jboss.messaging.destination:service=Queue,name=quickstart_helloworld_Request
java.lang.ClassCastException: org.jboss.jms.server.ServerPeer
at org.jboss.jms.server.destination.DestinationServiceSupport.startService(DestinationServiceSupport.java:107)
at org.jboss.jms.server.destination.QueueService.startService(QueueService.java:63)
--
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, 9 months