December 2006 - jboss-dev-forums - Jboss List Archives

[Design of POJO Server] - Re: Deployment through the ProfileService api

by scott.stark＠jboss.org

"charles.crouch(a)jboss.com" wrote : I just wanted to make sure I've got the right idea about the steps to deploy something which doesnt have an associated DeploymentUnit, e.g. no underlying -ds.xml, using the ProfileService apis: | | | a) From the ProfileService you call getProfile(ProfileKey key, String version). As we discussed on todays call the notion of version is going away, right? | Correct. "charles.crouch(a)jboss.com" wrote : | b) On the returned Profile you call getTemplate(String name). This name argument sounds like something for which there should be a definition around, e.g. static list of supported names? | | c) On the returned DeploymentTemplate call expand(Set values). Is Set<org.jboss.profileservice.spi.PropertyInfo> going to get replaced with Set<org.jboss.managed.api.ManagedProperty> or better yet just org.jboss.managed.api.ManagedObject? If so, thats another piece that requires a snapshot of jboss-managed.jar. Somehow expand() is also going to have to set the name attribute on the DeploymentContext it returns. | That is one way, but its not hooked up yet, and it needs to be synched up with the changes in the managed object api. The notion of a DeploymentTemplate was to create a deployment with preconfigured values coming from manged objects. We also need to actually create the templates. "charles.crouch(a)jboss.com" wrote : | d) On the Profile call addDeployment(DeploymentContext d) passing in the DeploymentContext returned from expand(). | | e) If the deployment fails an exception of some variety is thrown. | | Correct. However, for the initial tests I expect that the base deployment exists, so the way to add a deployment to a profile is: | URL deploymentURL = ... | VFS vfs = VFS.getVFS(deploymentURL); | VirtualFile deploymentVF = vfs.getRoot(); | AbstractDeploymentContext context = new AbstractDeploymentContext(deploymentVF); | ps.addDeployment(context); | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995976#3995976 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995976

17 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Valve on HAAspect

by timfox

can you explain the deadlock in more detail? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995974#3995974 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995974

17 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Valve on HAAspect

by clebert.suconic＠jboss.com

I have reactivated ValveAspect on my local box, and I had a dead lock with MessageCallbackHandler::copyState. Another thread was holding a lock to the MessageCallbackHandler while clientFailover was trying to call copyState whith a waiting to lock. I had to remove the lock, and I will probably commit this: | public void copyState(MessageCallbackHandler newHandler) | { | //synchronized (mainLock) | //{ | this.consumerID = newHandler.consumerID; | | this.consumerDelegate = newHandler.consumerDelegate; | | this.sessionDelegate = newHandler.sessionDelegate; | | this.serverSending = false; | | this.buffer.clear(); | //} | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995973#3995973 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995973

17 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Correct XA behaviour on closing a connection

by jeffdelong

I seem to recall having a similar issue using the WebSphere 5.1 Embedded JMS Server. It has been about 3 years or more so I am not crystal clear on all the details. I has a stateless session bean that I used to send JMS messages from a third party process engine as part of a global transaction. I needed to close the session after each message was sent because the WebSphere Embedded JMS Server was not thread safe, i.e. if one thread sent a message on the same session as a second message on another thread, the JMS server might get confused and throw an exception. But when I closed the session in the finally clause, the message did not get sent, because the transaction had not been commited. The solution in this case was to make the JMS session an instance variable and close it the next time the session bean method was invoked, and then create a new session each time. I guess my point is the "Jo dumb user" may need to close the session, to conserve resources or some other reason but has little control / knowledge of when the global transaction is going to commit. jBPM and hibernate have a similar issue. jBPM would typically tell hibernate to close the hibernate session when the jbpmContext is closed. Fortunately jbpm has a configuration option that can turn off this behavior in a managed environment. HIbernate also has configuration options to auto close session after transaction commits. It might be nice if there were a JMS server configuration option to say 'defer closing sessions until transaction commits' or something similar. That way the choice can be specified by the user, although I would vote to make this the default, since I think that most often with a user closes the session, they still expect the message to be sent. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995959#3995959 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995959

17 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Correct XA behaviour on closing a connection

by ovidiu.feodorov＠jboss.com

Tim wrote : Should the messaging resource manager, locally roll back (remove) the prepared state for that connection? Or it should it retain it, in the hope that the transaction manager will eventually call rollback or commit by obtaining an xaresource by recover() for instance? Second option (?) After all, the work is already part of the global transaction state, irrespective of the fact that connection (session) is closed or not. Tim wrote : I would be interested to know how JCA treats this. Does the JCA layer ever close connections that have XASessions that are still enlisted in a global tx, or does it never do this. Easy to find out. Model it ... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995948#3995948 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995948

17 years, 4 months

1
0
0 / 0

[Design of JBoss internal QA (Test Suite)] - Re: Code Coverage in JBoss AS Test Suite

by pavel.tsekov＠redhat.com

As I understand it the best way to capture coverage data in J2EE environments is by using offline instrumentation - custom class loaders won't work very well and as such runtime patching of the bytecode is not useful. I want to start testing EMMA and Clover on some real code from the JbossAS 4.2 testsuite - would you recommend any particular tests that I should test the code coverage tools with ? The testsuite is quite big but it is split in different categories. I'd like to get one test of each category and try the tools on it, but it's not easy for me to pick the right tests. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995947#3995947 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995947

17 years, 4 months

1
0
0 / 0

[Design of JBoss ESB] - Re: JMS Provider(s) Design - JBossMQ/JBossMessaging/ActiveMQ

by jeffdelong

Yes, I will check out latest from trunk this afternoon and test it out. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995937#3995937 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995937

17 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Deployment through the ProfileService api

by charles.crouch＠jboss.com

I just wanted to make sure I've got the right idea about the steps to deploy something which doesnt have an associated DeploymentUnit, e.g. no underlying -ds.xml, using the ProfileService apis: a) From the ProfileService you call getProfile(ProfileKey key, String version). As we discussed on todays call the notion of version is going away, right? b) On the returned Profile you call getTemplate(String name). This name argument sounds like something for which there should be a definition around, e.g. static list of supported names? c) On the returned DeploymentTemplate call expand(Set values). Is Set<org.jboss.profileservice.spi.PropertyInfo> going to get replaced with Set<org.jboss.managed.api.ManagedProperty> or better yet just org.jboss.managed.api.ManagedObject? If so, thats another piece that requires a snapshot of jboss-managed.jar. Somehow expand() is also going to have to set the name attribute on the DeploymentContext it returns. d) On the Profile call addDeployment(DeploymentContext d) passing in the DeploymentContext returned from expand(). e) If the deployment fails an exception of some variety is thrown. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995936#3995936 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995936

17 years, 4 months

1
0
0 / 0

[Design of JBoss ESB] - Re: JMS Provider(s) Design - JBossMQ/JBossMessaging/ActiveMQ

by daniel.brum＠jboss.com

Jeff, can you test this with the version in trunk? Would appreciate your feedback. quotes.st should be in a tb/quotes folder. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995906#3995906 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995906

17 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBMESSAGING-696 - Reference counting on Lease during fai

by clebert.suconic＠jboss.com

It looks like upgrading remoting to remoting-alpha4 fixed the bug. I will wait an input from Tom to see if this was already fixed. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995901#3995901 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995901

17 years, 4 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums December 2006