[JBoss Messaging] - Disabling ExpiryQueue in JBoss 5.1.0
by Veit Guna
Veit Guna [http://community.jboss.org/people/veitg] created the discussion
"Disabling ExpiryQueue in JBoss 5.1.0"
To view the discussion, visit: http://community.jboss.org/message/540192#540192
--------------------------------------------------------------
Hi.
We're using JBoss 5.1.0 and its standard message queue component. On deployment we create some queues via -service.xml files like so:
<mbean code="org.jboss.jms.server.destination.QueueService"
name="jboss.messaging.destination:service=Queue,name=myQueue"
xmbean-dd="xmdesc/Queue-xmbean.xml">
<depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
<depends>jboss.messaging:service=PostOffice</depends>
</mbean>
It seems that the default ExpiryQueue is always set to "ExpiryQueue" of JBoss. When messages expire, they are moved to that queue. Now
my question is, how can I disable it so the messages get simply dropped? Until 4.0.4 this seemed the default behavior - AFAIK. Setting ExpiryQueue to an empty string doesn't seem to do the trick - an error concerning mandatory occurs then. Any hints?
Also there seems the problem that messages get only expired, when a consumer is listening on the queue. Can this be automated with jboss messaging that comes with JBoss 5.1.0?
Thanks in advance.
Veit
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/540192#540192]
Start a new discussion in JBoss Messaging at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years
Re: [jboss-user] [JBoss Web Services Development] - CXF jms integration
by Alessio Soldano
Alessio Soldano [http://community.jboss.org/people/alessio.soldano%40jboss.com] replied to the discussion
"CXF jms integration"
To view the discussion, visit: http://community.jboss.org/message/540180#540180
--------------------------------------------------------------
Hi Jim,
I've taken a look at what you did in your jms-integration branches and have some questions / concers I'd like to discuss here. First of all let me summarize what you've done, so we're sure that we're all on the same page.
You basically added a deployment descriptor (jbossws-endpoints.xml) parsing that produces some new metadata in SPI (org.jboss.wsf.spi.metadata.endpoints.EndpointsMetaData). Those are later attached to the Deployment and used by EndpointsDescriptorsDeploymentAspect (cxf stack) to produce an instance of org.jboss.wsf.spi.metadata.endpoints.AbstractEndpointsDeployment (namely org.jboss.wsf.stack.cxf.deployment.CXFEndpointsDeployment), with a spring configuration file generated from the metadata. CXFEndpointsDeployment is later deployed by the KernelDeploymentDeployer and is responsible for generating the CXF Bus through the BusHolder, creating a new spi endpoint and adding it to the registry. Before handing over to the KernelDeploymentDeployer, the WSEndpointsRealDeployer (container integration) sets the proper depedencies for ensuring the bean is deployed after any JMS destination bean attached to the current deployment unit.
This said, here are my comments:
* jbossws-endpoints.xml: generally speaking, I would allow users to avoid providing that in most cases. AFAICS, the reason for that file is just in getting the information on which jms destinations are to be used for the endpoints included in the deployment. I think this can also be specified through a user provided jboss-cxf.xml, hence we need to allow for that too. Moreover, something else we should probably evaluate implementing (perhaps in CXF?) is an annotation for setting those destinations on the endpoint class (@JMSTransport or something like that). That said, yes, a user might still want to use xml for providing that info, in which case a configuration file like jbossws-endpoints.xml is fine. But I'd make that more JMS specific, as there's no need for it being generally for every endpoints, given http endpoints already have all the means of configuration in jbossws. So probably something like jms-endpoints.xml should be ok. Also the metadata naming should probably be reviewed
* new SPI metadata: besides the naming not completely convincing me, I think the few info we need (jms destination addresses currently) should live at the Endpoint level, not higher than that and separated from that as they currently are in jms-integration branch. Jim, did you evaluate having a hierarchy for the SPI Endpoint (with the current one becoming HttpEndpoint and a new JMSEndpoint having the destinations' info)? Still on this topic, we might probably create the SPI JMSEndpoint at the same time as the Http one (currently the WSDeploymentBuilder::build seems to me to be creating the Deployment only, while the Endpoint is actually created later by the CXFEndpointsDeployment). The CXFEndpointsDeployment should probably just do the endpoint registration (perhaps even that can unified..?), with already existing spi endpoints
* WSEndpointsReadDeployer: while I was not able to think about this solution before for the destinations dependency management, what I don't like here is that it's not part of our DA group. Where does it run in the deployers' chain? can we unify things here (make it a DA)?
* do you already know whether the proposed architecture is going to work with CXF 2.3 SOAP-over-JMS-1.0 support too ( http://cxf.apache.org/docs/soap-over-jms-10-support.html http://cxf.apache.org/docs/soap-over-jms-10-support.html)?
Thanks
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/540180#540180]
Start a new discussion in JBoss Web Services Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years
[JBoss Web Services] - Need advise on defining a webservice client for Teiid
by Ramesh Reddy
Ramesh Reddy [http://community.jboss.org/people/rareddy] created the discussion
"Need advise on defining a webservice client for Teiid"
To view the discussion, visit: http://community.jboss.org/message/540170#540170
--------------------------------------------------------------
Hi,
In http://teiid.org Teiid project, we provide "connectors" that consume XML based data from variety of sources including "web-services" for data integration purposes. Previously, Teiid was running in its own VM, so we provided custom web service client code using the JAX-WS "Dispatch" interface and Axis2's Call interface to invoke the web-service calls along with Teiid's own configuration.
In 7.0 release of Teiid, we are working towards integrating the Teiid into JBoss AS and re-evaluating our data consumption model. In this environment, we feel it is probably verbose for us to provide yet another way to configure web-service client. We want to use any predefined methods that are in work through JBossWS project.
The requirements are
- Should be able to invoke Doclitral/wrapped service
- Shoud be able to invoke a JAX-RPC based service
- REST support would be great
We want users to define a web-service client using some configuration in the AS, then when the user supplies the bound service name to the Teiid, Teiid should be dynamically able to invoke the call on the service and grab results. Dispatch is perfect, but all examples show them how to use in the code, not through configuration. We are willing to extend any technique to fit our needs. Any advise for us?
Thank you.
Ramesh..
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/540170#540170]
Start a new discussion in JBoss Web Services at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years
[JBoss Microcontainer Development] - Test Classes in main artifacts?
by Andrew Rubinger
Andrew Rubinger [http://community.jboss.org/people/ALRubinger] created the discussion
"Test Classes in main artifacts?"
To view the discussion, visit: http://community.jboss.org/message/540163#540163
--------------------------------------------------------------
Hi guys:
Came across this today in jboss-cl:
[alr@localhost ~]$ jar -tvf ~/.m2/repository/org/jboss/cl/jboss-classloader/2.2.0.Alpha4/jboss-classloader-2.2.0.Alpha4.jar |grep test
0 Fri Mar 12 08:47:08 GMT-05:00 2010 org/jboss/classloader/test/
0 Fri Mar 12 08:47:10 GMT-05:00 2010 org/jboss/classloader/test/support/
3019 Fri Mar 12 08:47:10 GMT-05:00 2010 org/jboss/classloader/test/support/IsolatedClassLoaderTest.class
994 Fri Mar 12 08:47:08 GMT-05:00 2010 org/jboss/classloader/test/support/IsolatedClassLoaderTestHelper$1.class
14268 Fri Mar 12 08:47:08 GMT-05:00 2010 org/jboss/classloader/test/support/IsolatedClassLoaderTestHelper.class
1155 Fri Mar 12 08:47:10 GMT-05:00 2010 org/jboss/classloader/test/support/MockClassLoaderHelper$1.class
1836 Fri Mar 12 08:47:10 GMT-05:00 2010 org/jboss/classloader/test/support/MockClassLoaderHelper$2.class
1604 Fri Mar 12 08:47:10 GMT-05:00 2010 org/jboss/classloader/test/support/MockClassLoaderHelper$3.class
1814 Fri Mar 12 08:47:10 GMT-05:00 2010 org/jboss/classloader/test/support/MockClassLoaderHelper$4.class
1919 Fri Mar 12 08:47:10 GMT-05:00 2010 org/jboss/classloader/test/support/MockClassLoaderHelper$5.class
1994 Fri Mar 12 08:47:10 GMT-05:00 2010 org/jboss/classloader/test/support/MockClassLoaderHelper$6.class
1763 Fri Mar 12 08:47:10 GMT-05:00 2010 org/jboss/classloader/test/support/MockClassLoaderHelper$7.class
1015 Fri Mar 12 08:47:10 GMT-05:00 2010 org/jboss/classloader/test/support/MockClassLoaderHelper$8.class
4854 Fri Mar 12 08:47:10 GMT-05:00 2010 org/jboss/classloader/test/support/MockClassLoaderHelper.class
1192 Fri Mar 12 08:47:10 GMT-05:00 2010 org/jboss/classloader/test/support/MockClassLoaderPolicy$1.class
9775 Fri Mar 12 08:47:10 GMT-05:00 2010 org/jboss/classloader/test/support/MockClassLoaderPolicy.class
Similar stuff in kernel:
[alr@localhost ~]$ jar -tvf /home/alr/.m2/repository/org/jboss/kernel/jboss-kernel/2.2.0.Alpha9/jboss-kernel-2.2.0.Alpha9.jar |grep test
0 Fri Mar 12 08:14:10 GMT-05:00 2010 org/jboss/test/
0 Fri Mar 12 08:14:10 GMT-05:00 2010 org/jboss/test/kernel/
0 Fri Mar 12 08:14:10 GMT-05:00 2010 org/jboss/test/kernel/junit/
8384 Fri Mar 12 08:14:10 GMT-05:00 2010 org/jboss/test/kernel/junit/MicrocontainerTest.class
9717 Fri Mar 12 08:14:10 GMT-05:00 2010 org/jboss/test/kernel/junit/MicrocontainerTestDelegate.class
These refer out to stuff in jboss-test (AbstractTestDelegate) and can lead to NCDFE when loaded. I assume they shouldn't be part of these artifacts?
S,
ALR
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/540163#540163]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years
[jBPM] - Spring JBpm 4.3 loading a custom IdentitySession
by Jaber C. Mourad
Jaber C. Mourad [http://community.jboss.org/people/newbeewan] created the discussion
"Spring JBpm 4.3 loading a custom IdentitySession"
To view the discussion, visit: http://community.jboss.org/message/540161#540161
--------------------------------------------------------------
Hi,
I'm trying to integrate spring and Jbpm.
I'm using the SpringHelper to start the processEngine :
<?xml version="1.0" encoding="UTF-8"?>
<jbpm-configuration>
<import resource="jbpm.tx.spring.cfg.xml" />
<import resource="jbpm.jpdl.cfg.xml" />
<import resource="jbpm.businesscalendar.cfg.xml" />
<import resource="jbpm.console.cfg.xml" />
<import resource="jbpm.jobexecutor.cfg.xml" />
<script-manager default-expression-language="juel"
default-script-language="juel"
read-contexts="execution, environment, process-engine, spring"
write-context="">
<script-language name="juel"
factory="org.jbpm.pvm.internal.script.JuelScriptEngineFactory" />
</script-manager>
<transaction-context>
<object class="identitySession"/>
</transaction-context>
<hibernate-session current="true" />
</jbpm-configuration>
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/540161#540161]
Start a new discussion in jBPM at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years
[jBPM] - jBPM DispatcherThread : J2SE and JEE behavior
by zecas zecas
zecas zecas [http://community.jboss.org/people/zecas] created the discussion
"jBPM DispatcherThread : J2SE and JEE behavior"
To view the discussion, visit: http://community.jboss.org/message/540157#540157
--------------------------------------------------------------
Hi,
I have a question that came when running jBPM in a J2SE environment.
I'm executing the following:
ProcessEngine processEngine = new Configuration().buildProcessEngine();
>From what I can tell, it will configure a process engine, and it will launch a thread, a "DispatcherThread" as it is called.
That thread will be the responsible to query the jbpm database (through hibernate), to check for executions to make.
That's what will keep the engine running.
My question is: What about web environments?
I've generated "user-webapp" through "ant create.user.webapp". It is under generated folder.
If I use it as a base for a single webapp or under JEE environment, it still lauches a thread? Is there any precaution to take in this environment?
What if I have several jbpm enabled applications, like J2SE and some webapps, all configured to use a central jbpm database repository for storing processes. How does each thread works? Are there any risk of complict? For example, multiple threads picking the same execution step to process.
Thanks.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/540157#540157]
Start a new discussion in jBPM at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years