"Hi Robert, can you elaborate further why you think
dynamic/runtime messaging destinations using JMSAdapter are not
viable?"
I edited my post shortly afterwards, see bolded text at the
bottom. I'd missed classes related to JMS config classes, I'd been
looking at the LCDS integrated messaging classes and assumed these
were supposed to be general purpose. I left the original post there
since I don't mind people knowing I make mistakes
Although.... I still haven't actually got this working yet,
and looking again with fresh eyes after a holiday, it looks like
the JMSSettings class can only contain 1 destination JNDI name, and
only one JMSSettings class can be attached to each JMS adapter.
Am I right in saying that this means a separate adapter will
need to be created for each temporary topic?
Perhaps I'm looking at it wrong, is there another mechanism
I've missed besides JNDI which Flex can use to find a JMS topic?
@tt9488
Did you make your new project with the correct Flex.war file?
If you used Peter Martins FDS plugin to create a new LCDS project
in eclipse, then ensure that it points to the correct flex.war
file, through the settings page (remember you can't change the FDS
war location on the new project dialog).
If you need to convert an old project, you can the old jars
and SWCs from the web-inf and meta-inf folders and extract the new
version from flex.war over the top (backup first) then redo your
config files using the new config templates in the resource folder
of LCDS 2.5.1. It gets really messy depending on how much you've
added it may be easier to make a new LCDS project and copy files
across to that. This can get pretty tricky.
I'm using LCDS 2.5.1 with the FB 2.0.1 plugin for eclipse
3.2.2 and it works a charm, although I so far have only upgraded
existing projects to LCDS 2.5.1 and not made any new ones.
Currently I'm working mainly with the SQLAssembler, but hopefully
I'll be returning to the dynamic JMS before too long.
edit:
Just been googling and I've seen you got quite a good
replyfrom Jeff Vroom, stating that the best approach might be to
translate JMS topics into LCDS subtopics by subclassing.. that
would certainly be more efficient than the idea I had when I
thought dynamic JMS was not at all viable, that is linking an MDB
to the dynamic JMS topic, and using this as a bridge to translate
messages to a dynamically created AS/LCDS topic. I'll post an
update if I get either approach working.