[Design of JBoss ESB] - Re: Configuration - normalization
by tfennelly
OK, we're back! But this time we can say we have truely reached a consensus. Kurt is going to add his name to this once he comes back from lunch - he promised :-)
So we've finally agreed on an approach that keeps both of us happy. We had a very detailed negotiation and we're both happy campers now. This doesn't undo any of the work we've been doing.
The config has 2 main sections - "providers" and "services". The providers section encapsulates the bus/channel info (we both hate the name "bus" here :-) ). Basically they're "Bus Providers" and there can be different types - JMS, FTP etc. The "services" section then defines the services - their Gateway and ESB Aware Listerns, Actions etc. The listeners reference whatever bus/channel it is that they receive messages on. Simple as that :-)
| <?xml version = "1.0" encoding = "UTF-8"?>
| <jbossesb xmlns="http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/etc/schemas/xml...">
|
| <providers>
| <jms-provider connection-factory="com.xyz.provider.XYZConnectionFactory"
| jndi-context-factory="....jboss"
| jndi-URL="xyz://server1:9876" jndi-pkg-prefix="com.xyz">
|
| <jms-bus busid="x-queue">
| <jms-message-filter dest-type="QUEUE" dest-name="queue/A" selector="service='Reconciliation'" />
| </jms-bus>
| <jms-bus busid="service-queue">
| <!--
| See how we add a JMS selector to this filter at the listener level. Look
| for listeners that use the "service-queue" bus.
| -->
| <jms-message-filter dest-type="QUEUE" dest-name="XYZ" />
| </jms-bus>
| </ms-provider>
|
| <jms-provider connection-factory="com.xyz.provider.XYZConnectionFactory"
| jndi-context-factory="....activemq"
| jndi-URL="xyz://server1:9876" jndi-pkg-prefix="com.xyz">
|
| <jms-bus busid="y-queue">
| <jms-message-filter dest-type="TOPIC" dest-name="topic/Z" />
| </jms-bus>
| </ms-provider>
|
| <ftp-provider some-ftp-provider-prop="blah-ftp-prop" ..... >
| <!--
| See how we specify a filter for this FTP bus at the listener level. Look
| for listeners the use the "blah-ftp-bus" jus.
| -->
| <ftp-bus busid="blah-ftp-bus" some-ftp-bus-param="x"/>
| </ftp-provider>
|
| </providers>
|
| <services>
| <service category="Bank" name="Reconciliation" description="Bank Reconciliation Service">
|
| <listeners>
| <!-- Gateway Listeners -->
| <jms-listener name="Reconciliation-JMS-Gateway"
| is-gateway="true"
| busidref="x-queue"
| maxThreads="1"/>
| <ftp-listener name="Reconciliation-FTP-Gateway"
| is-gateway="true"
| busidref="blah-ftp-bus">
| <ftp-message-filter dir="reconciliation" />
| </ftp-listener>
|
| <!-- The Service Listener -->
| <jms-listener name="Reconciliation-Service"
| is-gateway="false"
| busidref="service-queue"
| maxThreads="2">
| <jms-message-filter selector="service='Reconciliation'" />
| </jms-listener>
| </listeners>
|
| <actions>
| .......
| </actions>
|
| </service>
| <service category="Bank" name="Auditing" description="Bank Auditing Service">
|
| <listeners>
| <!-- Gateway Listeners -->
| <jms-listener name="Auditing-JMS-Gateway"
| is-gateway="true"
| busidref="y-queue"
| maxThreads="1"/>
| <ftp-listener name="Auditing-FTP-Gateway"
| is-gateway="true"
| busidref="blah-ftp-bus"
| busidref="blah-ftp-bus">
| <ftp-message-filter dir="auditing" />
| </ftp-listener>
|
| <!-- The Service Listener -->
| <jms-listener name="Auditing-Service"
| is-gateway="false"
| busidref="service-queue"
| maxThreads="2">
| <jms-message-filter selector="service='Auditing'" />
| </jms-listener>
| </listeners>
|
| <actions>
| ......
| </actions>
|
| </service>
| </services>
|
| </jbossesb>
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3994300#3994300
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3994300
19 years, 3 months
RE: [jboss-dev-forums] [Design of JBossCache] - Last chance for anychanges to the 2.0.0 API
by Brian Stansberry
I haven't thought about it in detail, but it sure sounds good. :)
jboss-dev-forums-bounces(a)lists.jboss.org wrote:
>
> TreeCacheProxyImpl
> Originally created as a delegate to link the new interfaces
> with TreeCache. I agree with earlier comments about this
> being unnecessary and TreeCache should just directly
> implement the new interfaces.
Was preventing people using TreeCache directly one of the original
motivations for this class and the factories and such? And therefore
calling various public methods that aren't part of the Cache interface?
If so, I'd think the biggest danger there is old code written to use
org.jboss.cache.TreeCache still working against 2.0. So perhaps we
change that class' name to CacheImpl or something. That breaks any code
that uses TreeCache directly, forcing use of the new API. If people
then still use the class directly rather than working through the
interfaces, well, that's their problem.
- Brian
19 years, 3 months
[Design of POJO Server] - Moving forward with the profile service mgmt api
by charles.crouch＠jboss.com
In the JBAS5 call this morning Adrian and I discussed how best we could proceed with fleshing out/writing tests for the management aspects of the profile service in parallel with Adrian developing the new managed object api and implementation. The conclusion that we came to was that the interface to Adrian's new managed objects would look quite similar to the ManagedObject/PropertyInfo interfaces we currently have. Therefore it should be possible to push ahead and build out the api's the profile service needs using the existing interfaces, and then refactor them when Adrian has committed his revised version. It should also be feasible to do the same with testcases, i.e. we write tests now and try to mock up/stub out interfaces that we require to get the tests going then come back and refactor later.
There is definitely going to be rework needed when Adrians stuff lands but at least this approach should enable forward progress to be made in related areas in the meantime. The plan is in the JBAS5 call next week for Adrian to provide an estimate on when the new managed object api and impl would be available.
Scott, does this approach make sense too you? Is it something you can push ahead with?
Thanks
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3994292#3994292
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3994292
19 years, 3 months
[Design of JBossCache] - Last chance for any changes to the 2.0.0 API
by manik.surtani＠jboss.com
Guys,
I hope to cut an ALPHA2 of JBC 2.0.0 soon. After this, I want to freeze the API so there are no more changes to it during beta/cr releases, so let's get this right.
The original API I proposed is on this wiki page.
Since then, due to lessons learned implementing the interfaces plus a lot of feedback from the community (esp. genman) the interfaces shipped with 2.0.0.ALPHA1 was sufficiently different. And now, even more so since shipping ALPHA1.
Most of the public API interfaces (CacheLoaders, CacheListeners, Regions) are ok, but some (Cache/CacheSPI/Node/NodeSPI) still needs work. Currently, these contain some changes from genman, but still pretty incomplete IMO.
Here is what the Cache and Node interfaces and their implementations looks like now:
Some notes:
Node and Cache
These are public API which will be used directly by client code (including HTTP session repl code)
NodeSPI and CacheSPI
These are plugin developers APIs, and are injected into CacheLoader and CacheListener implementations. They provide access to a richer set of functionailty, including access to RpcManagers, TransactionManagers, etc.
Now here are the bits I have gripes with.
TreeCacheProxyImpl
Originally created as a delegate to link the new interfaces with TreeCache. I agree with earlier comments about this being unnecessary and TreeCache should just directly implement the new interfaces.
DataNode/TreeNode/AbstractNode/WorkspaceNode malarky
This lot needs revisiting, a lot of it is legacy that has been retrofitted into the new interface structure.
As such, here is what I propose we do with the new structure, a great simplification:
Node and Cache, and their SPIs
These interfaces remain the same, offering the same functionality and public API. Cache no longer extends Node, purely for the sake of readability and reducing confusion. Cache will contain helper methods such as put(Fqn, Key, Value) but this will delegate to the root node.
TreeCacheProxyImpl
Is dropped, TreeCache directly implements CacheSPI
DataNode and TreeNode
are dropped, and AbstractNode directly implements Node. Basic functionality is implemented in this abstract class.
NodeSPI and WorkspaceNode
Since these offer different degrees of specialisation based on whether a node resides in a transaction workspace or not, there are 2 separate interfaces. Crucially, NodeSPI offers both versioning and locking information.
UnversionedNode
This is simply what used to be called NodeImpl, renamed to be a little more descriptive. Fulfils the contract of NodeSPI and is the object that is stored in memory when using pessimistic locking. Would throw UnsupportedOperationExceptions when versioning methods are invoked. Extends AbstractNode for base functionality.
VersionedNode
This is simply what used to be called OptimisticTreeNode, again renamed to be a little more descriptive and to break the implied fact that it is only used by optimistic locking. (At the moment this is the case but the only thing that differentiates it from other nodes is that it is versioned). Extends AbstractNode and UnversionedNode.
Please let me know what you think, this should result in a much more maintainable and readable structure.
Oh, and sorry about the long post! :-)
Cheers,
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3994225#3994225
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3994225
19 years, 3 months
[Design of JBoss jBPM] - Exception with Mysql during deployment
by anu123suya
Hi,
I could deploy a processdefinition in default hypersonic db. but when i try to deploy it in Mysql getting the following exception. have added users in the users table manually.
Can anyone let me know if i am missing something??
Thanks in advance
18:51:46,325 WARN [JpdlXmlReader] process xml warning: task references unknown
swimlane 'Applicant':<task xmlns="urn:jbpm.org:jpdl-3.1" name="ApplyLeave" swiml
ane="Applicant" blocking="false" signalling="true" priority="normal">
<controller config-type="field">
18:51:46,340 WARN [JpdlXmlReader] process xml warning: task references unknown
swimlane 'Applicant':
<controller config-type="field">
18:52:37,903 WARN [JDBCExceptionReporter] SQL Error: 1205, SQLState: 41000
18:52:37,903 ERROR [JDBCExceptionReporter] Lock wait timeout exceeded; try resta
rting transaction
18:52:37,903 ERROR [[jsp]] Servlet.service() for servlet jsp threw exception
org.hibernate.exception.GenericJDBCException: could not insert: [org.jbpm.graph.
def.ProcessDefinition]
at org.hibernate.exception.SQLStateConverter.handledNonSpecificException
(SQLStateConverter.java:91)
at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.j
ava:79)
at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelp
er.java:43)
at org.hibernate.persister.entity.AbstractEntityPersister.insert(Abstrac
tEntityPersister.java:1985)
at org.hibernate.persister.entity.AbstractEntityPersister.insert(Abstrac
tEntityPersister.java:2404)
at org.hibernate.action.EntityIdentityInsertAction.execute(EntityIdentit
yInsertAction.java:37)
at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:243)
at org.hibernate.event.def.AbstractSaveEventListener.performSaveOrReplic
ate(AbstractSaveEventListener.java:269)
at org.hibernate.event.def.AbstractSaveEventListener.performSave(Abstrac
tSaveEventListener.java:167)
at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId
(AbstractSaveEventListener.java:101)
at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.saveWithGene
ratedOrRequestedId(DefaultSaveOrUpdateEventListener.java:186)
at org.hibernate.event.def.DefaultSaveEventListener.saveWithGeneratedOrR
equestedId(DefaultSaveEventListener.java:33)
at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.entityIsTran
sient(DefaultSaveOrUpdateEventListener.java:175)
at org.hibernate.event.def.DefaultSaveEventListener.performSaveOrUpdate(
DefaultSaveEventListener.java:27)
at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.onSaveOrUpda
te(DefaultSaveOrUpdateEventListener.java:70)
at org.hibernate.impl.SessionImpl.fireSave(SessionImpl.java:524)
at org.hibernate.impl.SessionImpl.save(SessionImpl.java:514)
at org.hibernate.impl.SessionImpl.save(SessionImpl.java:510)
at org.jbpm.db.GraphSession.deployProcessDefinition(GraphSession.java:77
)
at org.jbpm.JbpmContext.deployProcessDefinition(JbpmContext.java:173)
at org.apache.jsp.Testdeploy_jsp._jspService(Testdeploy_jsp.java:51)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper
.java:332)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:3
14)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:173)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFi
lter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV
alve.java:213)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3994223#3994223
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3994223
19 years, 3 months