[JBoss Messaging Development] - Re: Sending messages from jboss to other application server(
by mnenchev
Up to now no success with this. I want just to send messages to websphere server. The people that develop the application using websphere gave me
queue.manager.name=...
queue.manager.host=...
queue.manager.port=...
queue.manager.channel=...
queuename=...
And told me to send messages there. How to do it no idea.
I tried this configuration:
<?xml version="1.0" encoding="UTF-8"?>
|
| <connection-factories>
|
| <!-- connection factory definition -->
| <tx-connection-factory>
| <jndi-name>TESTCF</jndi-name>
| <xa-transaction />
| <rar-name>wmq.jmsra.rar</rar-name>
| <connection-definition>javax.jms.ConnectionFactory</connection-definition>
| <config-property name="channel" type="java.lang.String">TEST.CHANNEL</config-property>
| <config-property name="hostName" type="java.lang.String">192.168.2.100</config-property>
| <config-property name="port" type="java.lang.String">1414</config-property>
| <config-property name="queueManager" type="java.lang.String">TESTQM</config-property>
| <config-property name="transportType" type="java.lang.String">CLIENT</config-property>
| <security-domain-and-application>JmsXARealm</security-domain-and-application>
| </tx-connection-factory>
|
| <!-- admin object definition -->
| <mbean code="org.jboss.resource.deployment.AdminObject" name="jca.wmq:name=testqueue">
| <attribute name="JNDIName">testqueue</attribute>
| <depends optional-attribute-name="RARName">
| jboss.jca:service=RARDeployment,name='wmq.jmsra.rar'
| </depends>
| <attribute name="Type">javax.jms.Queue</attribute>
| <attribute name="Properties">
| baseQueueManagerName=TESTQM
| baseQueueName=testqueue
| expiry=EXP_UNLIMITED
| </attribute>
| </mbean>
| </connection-factories>
|
It is deployed, but when i attempt to send message the QueueConnectionFactory lookup returns me ConnectionFactoryImpl
and so it throws classcastexception
Error:
java.lang.ClassCastException: com.ibm.mq.connector.outbound.ConnectionFactoryImpl cannot be cast to javax.jms.QueueConnectionFactory
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4263896#4263896
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4263896
14 years, 6 months
[JBoss Web Services Development] - Re: jms transport support in jbossws-cxf
by alessio.soldano＠jboss.com
"jim.ma" wrote :
| "alessio.soldano(a)jboss.com" wrote :
| | - consider taking a look at the CXF JMSTransportFactory, perhaps there's an easy hook for getting/setting the address. We currently overwrite the SoapTransportFactory in the bus in CXFServletExt.loadBus(..) in order to implement our own soap address rewriting rules for http endpoints. Perhaps a similar approach might be useful here (extending the jms transport factory, etc.) for the jms case.
| Do you mean we can specify the jms address in servlet initial parameter and set it in the JMSDestination when initialize servlet ?
|
No, I don't think allowing the jms address to be provided in servlet initial parameters is useful, considering the same can already be achieved using the other descriptor (jbossws-cxf.xml).
What I'm thinking about is that you can probably define a new JMSTransportFactory that extends the original one and also uses the information regarding the jms stuff to update the endpoint address in the registry. That information is basically the JMSConfiguration that is currently computed in the jms transport factory.
Besides this, I was actually thinking about something else. Another interesting think to do would be to consider the jms endpoints too in the endpoint metrics that we provide (the count of messages, etc.). This is something we can deal with later, but keep an eye for possible integration points, idea, etc.
"jim.ma" wrote :
| "alessio.soldano(a)jboss.com" wrote :
| | - we might think about something (an annotation?) to mark a jms endpoint when doing java-first, assuming there's not an equivalent way in CXF yet. That could be looked for in the DA to properly write the jbossws-cxf that is generated on the fly when not provided by the user.
|
| Annotation is another way to specify jms transport and address. IMHO, It's flexible to define the jms configuration in web.xml. You do not need to compile the code when you change the queue name .
|
Yes, I see what you mean, let's stick with the descriptor for now (the jbossws-cxf.xml)
"jim.ma" wrote :
| "alessio.soldano(a)jboss.com" wrote :
| | - is the CXF JMSFeature (http://cxf.apache.org/docs/using-the-jmsconfigfeature.html) configuration of any use to us?
| IMO, it is another format to attach the jms configuraiton to the client and endpoint. If user provides the jbossws-cxf.xml like this format , we do not support to parse ,extract the jms address information and register the endpoint. We will just support one format like the jbossws-cxf.xml in current jms transport sample.
OK
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4263872#4263872
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4263872
14 years, 6 months
[JBoss Web Services Development] - Re: jms transport support in jbossws-cxf
by jim.ma
Thanks for your input , Alessio.
"alessio.soldano(a)jboss.com" wrote :
| - consider taking a look at the CXF JMSTransportFactory, perhaps there's an easy hook for getting/setting the address. We currently overwrite the SoapTransportFactory in the bus in CXFServletExt.loadBus(..) in order to implement our own soap address rewriting rules for http endpoints. Perhaps a similar approach might be useful here (extending the jms transport factory, etc.) for the jms case.
Do you mean we can specify the jms address in servlet initial parameter and set it in the JMSDestination when initialize servlet ?
<servlet>
| <servlet-name>MyServletName</servlet-name>
| <servlet-class>com.mycompany.MyServlet</servlet-class>
| <init-param>
| <param-name>jmsJndiRequestQueue</param-name>
| <param-value>queue/RequestQueue</param-value>
| </init-param>
| </servlet>
"alessio.soldano(a)jboss.com" wrote :
| - we might think about something (an annotation?) to mark a jms endpoint when doing java-first, assuming there's not an equivalent way in CXF yet. That could be looked for in the DA to properly write the jbossws-cxf that is generated on the fly when not provided by the user.
Annotation is another way to specify jms transport and address. IMHO, It's flexible to define the jms configuration in web.xml. You do not need to compile the code when you change the queue name .
"alessio.soldano(a)jboss.com" wrote :
| - is the CXF JMSFeature (http://cxf.apache.org/docs/using-the-jmsconfigfeature.html) configuration of any use to us?
IMO, it is another format to attach the jms configuraiton to the client and endpoint. If user provides the jbossws-cxf.xml like this format , we do not support to parse ,extract the jms address information and register the endpoint. We will just support one format like the jbossws-cxf.xml in current jms transport sample.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4263846#4263846
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4263846
14 years, 6 months
[JBoss Microcontainer Development POJO Server] - Re: Cleanup path for Structure Deployers
by david.lloyd＠jboss.com
"alesj" wrote :
| Thinking about how to hack this non-automount approach. ;-)
| e.g.
| Lets say we just have component deployers (probably not gonna happen, but still ...),
| no parsing stuff, nothing that would need to touch resources, hence no VFS usage.
| But we have a bunch of pre-attached component metadatas,
| meaning those component deployers would pick this up and deploy it.
| And one of our services at runtime calls URL.inputStream on a location that is sure it exists, but as an inner resource (double nested jar entry).
| What would happen in this case or how you make sure this is mounted and unmounted?
|
In this case the service is just not going to work unless the archive is mounted through one of the mechanisms designed to do so:
- A deployer mounting a deployment
- A deployer mounting a classpath element
- User code using the deployer API to mount the resource
There is one option for auto-loading external JARs like you mention - do some type of archive detection (maybe read the first four bytes to identify whether it's an archive), automount if necessary, and assign the handle to whatever deployment owns the caller's classloader. Of course if no deployment owns the classloader, it won't work. Anyway this would probably be something we could add later?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4263830#4263830
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4263830
14 years, 6 months
[JBoss Microcontainer Development POJO Server] - Re: AS weld-int
by alesj
It should be then the job of WeldKCC to cleanup this intermediate bean (IB).
e.g.
BMDD + WeldKCCC --> IB
IB::start --> WeldKCC and add DepItem on WeldKCC for IB to be Installed
* WeldKCC depends on Installed IB in X
* WeldKCC uninstalls IB in X+1
It looks a bit hackish, but that's the cost of tying WeldKCC with BootstrapBean.
And if I'm not yet too sleepy, this should properly cleanup.
Actually, there is another cleanup issue to take care of. ;-)
e.g. WeldKCCC adds IB, but BootstrapBean is never installed (for whatever reason)
This would leave IB hanging in Controller + you would get error for Controller::uninstall("real-weld-bean-name")
We should track this mapping as well
* removing it once WeldKCC is installed and IB removed
* actually removing IB from Controller instead of WeldKCC if the mapping is still there
(this would mean that the BB was never installed)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4263828#4263828
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4263828
14 years, 6 months
[JBoss Microcontainer Development POJO Server] - Re: AS weld-int
by kabir.khan＠jboss.com
"kabir.khan(a)jboss.com" wrote :
| I will see if I can make 'vfs://top-level.ear/BootstrapBeanInstaller=SimpleBean' uninstall itself, but it feels a bit strange to do that from its start() method.
It leaves the context in an inconsistent state
| public void start() throws Exception
| {
| BeanDeploymentArchive archive = deployment.getBeanDeploymentArchives().iterator().next();
|
| if (deployment.getBeanDeploymentArchives().size() > 1)
| log.warn("More than one bean deployment archives, using the first " + archive);
|
| BeanManager manager = bootstrapBean.getBootstrap().getManager(archive);
| if (manager == null)
| throw new IllegalStateException("Could not find a manager for archive " + null);
|
| WeldKernelControllerContext ctx = new WeldKernelControllerContext(null, beanMetaDataHolder.getBeanMetaData(), null, manager);
|
| try
| {
| context.getController().install(ctx);
| }
| catch(Exception e)
| {
| throw e;
| }
| catch(Throwable t)
| {
| throw new Exception(t);
| }
| finally
| {
| ControllerContext me = context;
| context.getController().uninstall(context.getName());
| System.out.println(me);
| }
| }
|
context is the context of the bean. The call to uninstall completes successfully, unconfiguring the target and setting it to null. However, when StartStopLifecycleAction completes and ends up back in incrementState() the context is picked up and moved through the remainder of the states.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4263813#4263813
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4263813
14 years, 6 months