Firstly, please do not cross post.
I deleted the exact same post you posted on the design forum.
Secondly, 1.2.0 version is fairly old now, if you are installing from new why
aren't you using 1.4.0?
The error you are getting is probably because you didn't follow the
installation instructions
This looks like a remoting bug that was fixed some time ago.
You should try remoting and JBM.
http://jira.jboss.com/jira/browse/JBREM-732
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4099551#4099551
Reply to the post :
balkanboy wrote : Hail to the JBoss Messaging gurus (Tim, et al.) - I
installed JBM 1.4GA as outlined in the manual on a clean JBoss 4.2.2AS
installation, and I am getting the following exception:
|
| anonymous wrote :
| | 17:30:21,541 ERROR [ExceptionUtil]
What's max delivery attempts set to in your MDB container config?
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4099482#4099482
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4099482
Please post your HTTPSConnectionFactory config.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4098802#4098802
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4098802
___
jboss-user
Madhu-
I'm not sure i understand your question. Can you elaborate / rephrase ?
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4098799#4098799
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4098799
You're in the wrong forum.
RedeliveryLimit is a JBoss MQ attribute, not a JBoss Messaging attribute.
This forum is for JBoss Messaging users.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4098808#4098808
Reply to the post :
You must have changed the fullSize parameter for your destination.
If you change it back to its original value it shoud work.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4098810#4098810
Reply to the post :
No.
That defeats the purpose of using a topic, since you'd have to effectively
serialize delivery across all consumers.
If you want that use a queue.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4098848#4098848
Reply to the post :
This is really a JBoss Remoting question, not a JBM question.
I can ping Ron to take a look, or you can repost on the remoting forum.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4098850#4098850
Reply to the post :
Madhu-
I'm not sure if I understand your question still.
a) Clearly each individually subscriber receives messages in order. Is that
what you mean?
b) Or do you mean that each consumer receives the same particular message
before receiving the same particular message?
b) would be extremely
Hi btsibr-
Sorry, we will answer this in due course. We're just very busy at the moment!
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4097144#4097144
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4097144
There's no way to do this automatically currently.
If you like you could add a feature request in JIRA to add a parameter which if
true would enable message counters on start up.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4097143#4097143
Reply to the post
I have seen something similar when the patched remoting 2.2.2.SP1 jar is not
used on the client side.
Are you sure you have
a) Dropped the jar into the server/your config name/lib directory on the
server?
b) Added the jar as the first entry on your client classpath?
View the original post :
If the call to send a persistent message to a persistent destination returns
successfully with no exception, then you can be sure that the message was
persisted.
However if the call doesn't return successfully e.g. if an exception is thrown,
then you *can't be sure the message wasn't
If the call to send a persistent message to a persistent destination returns
successfully with no exception, then you can be sure that the message was
persisted.
However if the call doesn't return successfully e.g. if an exception is thrown,
then you *can't be sure the message wasn't
genman wrote :
| But you can implement a pretty decent solution on the client side by
generating your own unique business transaction ID and processing on the
consumer side only if that transaction ID was never processed before.
Yes indeed.
Discarding duplicates is a very powerful solution
You may have luck scoping on the server side, but the main problems are on the
client side (where you can't scope).
You'll need to have the JBM latest versions of remoting on the client classpath
before anything else, and this may not work well with the other things from
JBAS 4.0.5 which need
Hi-
There are some pretty thorough instructions on how to deploy JBoss Messaging in
JBoss AS 4.2.x in the JBoss Messaging user guide.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4094526#4094526
Reply to the post :
Ok, I believe this is now fixed in TRUNK.
You could take it for a spin if you like?
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4094523#4094523
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4094523
Madhu-
Please feel free to add a feature request in JIRA
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4094527#4094527
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4094527
___
There's no way of doing this using the JMX API in a single call - you'll need
to connect to each node and deploy it individually.
Or you could write some code that uses the farm service to deploy to all nodes
(like when you drop the deployment descriptor in the farm directory).
View the
This looks like something that was fixed back in July for the 1.4.0.CR1 release
http://jira.jboss.com/jira/browse/JBMESSAGING-1005
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4093380#4093380
Reply to the post :
If you're running Linux, pstree is a nice utility which displays your processes
in a tree. It should be pretty clear to see from that the processes
corresponding to the script and java itself.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4093417#4093417
Exact figures depend very much on the hardware being used, and if using
persistent messages the type and tuning of the database being used for
persistent messages.
Having said that 500K msgs in 8 hours doesn't seem that much.
View the original post :
Yes, I can confirm that whoever completed the task, did not finish it
properly.
I''ll reopen it and make sure it gets done properly this time.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4093543#4093543
Reply to the post :
Yes indeed, a bug it is...
http://jira.jboss.com/jira/browse/JBMESSAGING-1100
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4093163#4093163
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4093163
'tis fixed in TRUNK
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4093169#4093169
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4093169
___
jboss-user mailing list
Madhu-
Please can you describe what you are doing in more detail?
Note that Redelivery delay is RE-delivery delay, not delivery delay.
I.e. the intention is not to delay the first delivery of the message, but to
delay any subsequent deliveries that may occur after rollback.
If you want to
We currently have an early adopter program which includes several household
names who have been using JBM in production for some time.
We also have many other non production support customer using JBM and many more
again non paying customers using JBM in production.
Currently only developer
If you catch your exception and rollback your transaction, then the message
should automatically get redelivered.
(This should happen automatically for your in a transacted MDB).
To prevent roll backs happen in too quick a succession you can specify a
redelivery delay (see userguide for more
LeifOO wrote :
| Question about jboss-remoting 2.2.2.SP1 jar:
| Chapter 4, JBoss Messaging Installation,
|
http://labs.jboss.com/file-access/default/members/jbossmessaging/freezone/docs/userguide-1.4.0.GA/html/installation.html
| states that you shall download jboss-remoting 2.2.2.SP1
[Moved to EJB forum]
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4092490#4092490
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4092490
___
jboss-user mailing list
http://jira.jboss.com/jira/browse/JBMESSAGING-1098
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4092506#4092506
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4092506
___
julians37 wrote :
| Does this makes sense or would you consider this to be an abuse of the
expiry feature? Do you see a way of implementing this in another way, maybe
using temporary topics and a DLQ? (Right now I'm not using temporary topics for
responses - instead I use a global response
Hi-
Are you still having problems with this? I'd like to close the task...
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4091900#4091900
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4091900
You should use persistent messages and durable subscriptions, then your
messages will survive failure.
Persistent messages in a non durable subscription act as non persistent
messages. Non persistent messages do not survive failure. See JMS spec for more
details.
View the original post :
[Moved to user forum from design forum]
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4090123#4090123
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4090123
___
jboss-user mailing
Also make sure you're using a clustered connection factory (e.g. the one at
/ClusteredConnectionFactory) - the default one doesn't have transparent
failover.
See the user guide for more details.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4090124#4090124
Hello Craig-
I know this is probably not what you want to hear, but you should really
consider upgrading to the latest version of JBM.
Since 1.0.1.GA we have made a lot of fixes / changes, and also lots of issues
have been fixed in JBoss Remoting. The one you are seeing could be one of the
julians37 wrote : Since there's been no follow-up,
|
Sorry have been travelling all last week!
anonymous wrote :
| From this point on it's not about solving a problem of mine but rather I'm
just making suggestions as to how JBM as a product could become better by
making its setup and its
Looks like you've perhaps installed different versions of remoting on the
client and server.
In any case, 1.4.0.GA has just been released.
You could try this, following the installation instructions exactly, and
testing if the examples then work (see user guide).
Thx
View the original post :
julians37 wrote :
| Any chance that a JBM developer could chime in and let me briefly know
whether this is actually meant to work? If it's meant to be that
straightforward, why the discussion about queue reapers and scalability?
|
Julian - could you explain in a bit more detail about what
jinoinfo- JMS_MESSAGES is a JBoss MQ table, not a JBoss Messaging table.
This forum is about JBoss Messaging, not JBoss MQ. You should post on the JBoss
MQ forum.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4090016#4090016
Reply to the post :
fuzzybinary wrote : Does that mean I have to set up two instances on the same
machine at the same IP? If so, does one of the examples allow me to test a
distributed queue on two separate machines?
|
| (Sorry, not at work and not close to the documentation at the moment. Will
double check
navjeetc wrote : Tim,
|
| In that case is there any point in trying with JBoss messaging 1.4.0 CR3 as
suggested earlier or not?
No. This is just normal JTA behaviour, not a JBM bug.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4089592#4089592
Reply to
navjeetc wrote :
|
| Is this expected behaviour
|
Yes, this is expected behaviour.
This has been covered on a previous thread
http://www.jboss.org/index.html?module=bbop=viewtopict=112873
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4089433#4089433
julians37 wrote : Ah! Fair enough, but the bit of documentation you're
linking to says:
|
| anonymous wrote :
| | 6.1.1.1. ServerPeerID
| |
| | The unique id of the server peer. Each node in the cluster must have a
unique name.
| |
|
| Note that it says each node in
julians37 wrote : To elaborate, it feels wrong that if you set up a bridge to
send messages somewhere, to some remote JMS provider, that you have to know
details about the way that remote provider is configured.
|
I don't follow, what details do you have to know?
anonymous wrote :
| It
julians37 wrote : That's definitely a workaround I can live with.
|
Well, it's not really a workaround, that's the way JBM servers are configured.
Each one must have a unique id.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4087620#4087620
Reply to the
DB2 is not currently a supported database, please see the wiki page for a list
of supported databases.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4087647#4087647
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4087647
If you can come up with a solution that doesn't require each node to have a
unique server id then we're all ears.
Believe me, it's not trivial or we would have done it already.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4087648#4087648
Reply to the post :
http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossMessagingDatabaseCompatibilityMatrix
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4087649#4087649
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4087649
If I follow your instructions exactly I can replicate the issue.
However it looks like you skipped a stage in the installation of messaging2 -
you need to give it a unique server id.
Does the bridge example (in the distro) work for you?
If so, I would suggest starting from that working baseline and changing the
example step by step until it resembles you're desired setup.
At some step you should figure what's going wrong.
View the original post :
I just tested with the current TRUNK against AS 4.2.1.GA.
I ran the bridge example after setting the QOS mode to 2 and it works ok:
| sleep:
| [echo] Sleeping for 5 seconds ...
|
| run:
| [java] Queue JBossQueue[A] exists
| [java] Queue JBossQueue[B] exists
|
JBoss Messaging 1.4.0.CR3 has been released and is available for download.
http://labs.jboss.com/jbossmessaging/downloads/jboss-messaging-1.4.0.CR3.zip
This is a candidate release for JBoss Messaging 1.4.0.
Please see the release notes for the description of the release.
Important note! This
Sure, just use the JNDIName attribute:
http://labs.jboss.com/file-access/default/members/jbossmessaging/freezone/docs/userguide-1.4.0.CR2/html/configuration.html#conf.destination.queue.attributes.jndiName
View the original post :
JBM doesn't want an xa datasource.
Just use a standard datasource, an example can be found in the
docs/examples/jca directory of the JBoss AS distribution - oracle-ds.xml
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4086634#4086634
Reply to the post :
This is a JBoss MQ question, please post on the JBoss MQ forum.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4086635#4086635
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4086635
Yes this was fixed in 1.3.0, so an XA session which is not enlisted in a JTA
tx falls back to acting as non transacted (auto_ack).
The whole story is rather complex.
For some use cases (like the reported one) an XASession needs to act as non
transacted when not enlisted in a tx.
But in other
I'm pleased to announce the JBoss Messaging team is growing. :)
We have recruited two new engineers who will be working full time on JBM.
Andy Taylor. Andy is an experienced engineer who has worked in the past for HP
- on RMI-IIOP, and for Arjuna where he developed their JMS implementation.
I think I know what the problem is by looking at the code, I just haven't
managed to replicate here, I guess I just haven't managed to get the race.
Anyhow, I can add a fix even though I can't replicate, hopefully will have
this done in before the end of the week. If you could then try that
mskonda wrote :
| I am using JmsXA conenction factory in JBM 1.2.SP2
|
Don't use JmsXA.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4085971#4085971
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4085971
I have done a prospective fix in SVN TRUNK - can you give it a spin?
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4086262#4086262
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4086262
1.0.1.SP5 is the final release in the 1.0 series.
However I wouldn't recommend 1.0 since this is now *old* and no new work is
being done on it.
I recommend trying out 1.4.0. The GA will be out soon.
View the original post :
mclu-
Can you try setting maxBatchTime to -1 and tell me if the problem still occurs?
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4085397#4085397
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4085397
I have tried to replicate this locally but cannot.
If you could try and replicate in a test program ASAP that would be a great
help, otherwise it's unlikely the fix (if required) will be ready in time for
the next release.
View the original post :
aslak wrote : When creating a Temporary destination on a clustered
PostOffice,
| the temp destination itself is clustered but..
|
| Both nodes in the cluster fail adding a MessageSucker to the temp
destination due to a SecurityException.
|
| The node that received the message
I believe you are using JBM 1.3.0?
There have been many fixes in clustering since then, I suggest you try out
1.4.0.CR2 and report back if your problem still occurs.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4085514#4085514
Reply to the post :
The queue/topic name should not contain a slash.
If you want to deploy the queue/topic at a specific place in the JNDI tree
(e.g. /a/b/) then use the JNDIName attribute for this.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4084969#4084969
Reply to the post
jw.1 wrote : Hi
|
| Are transactions supported when using http(s) as transport?
|
|
Yes
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4084976#4084976
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4084976
You didn't say what versions you are using.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4084977#4084977
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4084977
___
jboss-user
CR2 has been released
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4084980#4084980
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4084980
___
jboss-user mailing list
Thanks - I have updated the docs to reflect this
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4084983#4084983
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4084983
___
jboss-user
This looks like your database has gone down
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4084985#4084985
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4084985
___
jboss-user
This is not an error (note it is logged at WARN).
MySQL has the interesting habit of being able to get a deadlock even when
inserting one row. See the MySQL web site for more details.
To deal with this, we catch it and retry. You can safely ignore this.
View the original post :
Are you sure you are running Remoting 2.2.2.GA as specified in the release
announcement?
If so, maybe you are not closing your connections?
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4084988#4084988
Reply to the post :
http://jira.jboss.com/jira/browse/JBMESSAGING-1069
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4084989#4084989
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4084989
___
Can you reproduce this in a simple test case?
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4084992#4084992
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4084992
___
jboss-user
http://jira.jboss.com/jira/browse/JBMESSAGING-1070
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4084991#4084991
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4084991
___
http://jira.jboss.com/jira/browse/JBMESSAGING-1068
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4084993#4084993
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4084993
___
We don't currently support file storage - we will support this in JBM 2.0
however.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4084997#4084997
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4084997
1.3.0 has issues with isolation.
These were fixed in 1.4.0 IIRC.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4084998#4084998
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4084998
I believe this is related to
http://www.jboss.com/index.html?module=bbop=viewtopict=98577postdays=0postorder=ascstart=40
The problem occurs because of this code in SessionAspect:
|/** http://jira.jboss.org/jira/browse/JBMESSAGING-946 - To accomodate
TCK and the MQ behavior
| *
We haven't tested this configuration, but if you give every node a unique
server peer id, you should be able to run multiple clusters using the same DB
instance, although of course that may introduce scalability issues.
View the original post :
You didn't say which versions you are using.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4085141#4085141
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4085141
___
jboss-user
bob_walker99 wrote : Hi,
| I've been seeing this for a while and alsways put it down to classpath
issues, but I'm quite an expert at which jboss client jars work and which
don't, and what needs to go where, so I'm no longer convinced that this is the
issue.
|
With JBM 1.4 the jars are
Fixed in TRUNK.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4085178#4085178
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4085178
___
jboss-user mailing list
If I remember rightly, the problem was due to the Spring JMS template doing
some really nasty stuff like opening a connection for each message sent (or
consumed - I can't remember).
So if you're using Spring template with a standard JMS connection factory
you're going to get these horrible
There's no requirement to use jbossall-client.jar - it's just for convenience.
Instead you can just use the individual jars from the client directory of the
JBoss AS distribution.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4077563#4077563
Reply to the post
See the WIKI
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4075526#4075526
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4075526
___
jboss-user mailing list
With persistent messages normally the database is the bottleneck.
There's not a lot that can be done about that as long as we use a database for
persistence.
Having said that, last time we measured JBM was significantly faster than JBoss
MQ even for persistent messages.
IN JBM 2.0, we will be
Ok, I will try again this coming week.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4075528#4075528
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4075528
___
jboss-user mailing
What version of Oracle (and driver) are you using?
We test against 10.1 currently.
Looks like the version you are using doesn't support using streams in a batch
update.
You can try turning batch updates off, or not to use binary streams, see the
persistence manager config section in the user
Can you post a failing code example?
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4074676#4074676
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4074676
___
jboss-user mailing
Did you make sure that the name of your new MySQL datasource is referenced from
the mysql-persistence-service.xml.
By default mysql-persistence-service.xml uses DefaultDS so you will have to
change this.
There are 6 places in myqsl-persistence-service.xml that need to be updated (do
a search
But the real reason, as Clebert has pointed out, is probably that when you
installed you created a non clustered hsql installation (hsql can't be used for
a clustered install) - you will notice clustered=false in the
hsql-persistence-service.xml.
When you copied over
Regarding your jgroups issue, take a look at this
http://www.jboss.org/index.html?module=bbop=viewtopict=116217 thread.
I suspect your making the same mistake (trying to enable clustering in a non
clustered installation)
View the original post :
aslak wrote : Actually, the ActiveMQMessage converts the JbossDestination to
a ActiveMQDestination. Then the ActiveMQMessage is converted to a JbossMessage
with the ActiveMQDestination still set, hench the ClassCastException.
|
|
| :o)
|
Ok fair enough. But the same fix should work
801 - 900 of 1586 matches
Mail list logo
