August 2008 - jboss-dev-forums - Jboss List Archives

[Design of JBoss Deployment Framework] - Re: Russian doll packaging in arbitrary directories - JBAS-5

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : | so If there was also a | | parent.jar/child/WEB-INF/lib/util.jar | | it would be wrong to treat util.jar as a subdeployment since it is part of the | war classpath. Which basically means the "DirectoryStructure" has to come after other StructureDeployers so when the WARStructure recognises the "child" directory it doesn't get processed by the DirectoryStructure. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4173375#4173375 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4173375

16 years, 4 months

1
0
0 / 0

[Design of JBoss Deployment Framework] - Re: Russian doll packaging in arbitrary directories - JBAS-5

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : | 1) We could create a new but deprecated "DirectoryStructure" that adds this behaviour | for backwards compatiblity purposes. | i.e. instead of ignoring directories inside deployments that don't have | a META-INF subfolder, we could scan them (recursively) for deployments. | This solution has the problem that directories no longer need extensions to be deployable. e.g. parent.jar/child/WEB-INF/web.xml makes "child" a valid web application subdeployment. so If there was also a parent.jar/child/WEB-INF/lib/util.jar it would be wrong to treat util.jar as a subdeployment since it is part of the war classpath. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4173371#4173371 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4173371

16 years, 4 months

1
0
0 / 0

[Design of JBoss Deployment Framework] - Russian doll packaging in arbitrary directories - JBAS-5900

by adrian＠jboss.org

https://jira.jboss.org/jira/browse/JBAS-5900 This raises the issue of a change in behaviour in "Russian doll" packaging in JBoss5. The behaviour asserted is actually not tested in the AS testsuite, instead it is documentated to be otherwise, see "Deploy Applications Inside of An Application" here: http://docs.jboss.org/jbossas/upgrade4/html/ "If you want to make a subdeployment (for those archives that support simple Russian Doll packaging), place it in the root of the parent deployment." (My emphasis) Possible Solutions: 1) We could create a new but deprecated "DirectoryStructure" that adds this behaviour for backwards compatiblity purposes. i.e. instead of ignoring directories inside deployments that don't have a META-INF subfolder, we could scan them (recursively) for deployments. 2) We could add something to that treats directories like "lib" specially and scans them for jars, since this is becoming a standard within JavaEE. 3) Close the issue saying it was an "undocumented feature" View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4173370#4173370 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4173370

16 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Management operation over JBM 2 Core API

by jmesnil

"timfox" wrote : "jmesnil" wrote : | | | | The management clients will send management messages to this standard management messages. | | | | However, it needs to be able to consume the replies. | | My idea was that he still would have to create a temp queue and a destination used as the "reply-to" of the management messages. | | | | | | | | if I send a management message to admin destination "create Temp Queue", and also specify that destination as the reply for the management message, then surely it will create that destination, then send the reply back there. | | So you can still consume the replies, no need for extra create/delete queue methods? Sure you can, but I find this more convoluted than having a explicit create/delete queue methods. Besides, creating temp queues is done in many messaging patterns and I'd prefer to keep a method to do that as part of our core API without relying on management API. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4173369#4173369 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4173369

16 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Management operation over JBM 2 Core API

by timfox

"jmesnil" wrote : | | The management clients will send management messages to this standard management messages. | | However, it needs to be able to consume the replies. | My idea was that he still would have to create a temp queue and a destination used as the "reply-to" of the management messages. | | | if I send a management message to admin destination "create Temp Queue", and also specify that destination as the reply for the management message, then surely it will create that destination, then send the reply back there. So you can still consume the replies, no need for extra create/delete queue methods? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4173367#4173367 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4173367

16 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Management operation over JBM 2 Core API

by jmesnil

"timfox" wrote : "jmesnil" wrote : | | Yes, we still need them to create the destination and the (temp) queue which is used to receive the management messages | | Seems a bit odd. | | If we have a standard management destination this shouldn't be necessary surely? | The management clients will send management messages to this standard management messages. However, it needs to be able to consume the replies. My idea was that he still would have to create a temp queue and a destination used as the "reply-to" of the management messages. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4173362#4173362 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4173362

16 years, 4 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: mavenize enterprise

by thomas.diesler＠jboss.com

I think this done actually. If you follow http://jbpm.dyndns.org/jbpmwiki/index.php?title=JBPM3BuildingTheInstaller you should see the jbpm-console working and the enterprise beans deploy | 16:56:00,550 INFO [ConnectionFactoryBindingService] Bound ConnectionManager 'jboss.jca:service=DataSourceBinding,name=JbpmDS' to JNDI name 'java:JbpmDS' | 16:56:00,865 INFO [ConnectionFactoryBindingService] Bound ConnectionManager 'jboss.jca:service=ConnectionFactoryBinding,name=JmsXA' to JNDI name 'java:JmsXA' | 16:56:01,638 INFO [EjbModule] Deploying TimerEntityBean | 16:56:01,983 INFO [EjbModule] Deploying CommandServiceBean | 16:56:02,107 INFO [EjbModule] Deploying TimerServiceBean | 16:56:02,113 INFO [EjbModule] Deploying CommandListenerBean | 16:56:02,182 INFO [EjbModule] Deploying JobListenerBean | 16:56:04,193 INFO [BaseLocalProxyFactory] Bound EJB LocalHome 'TimerEntityBean' to jndi 'java:ejb/TimerEntityBean' | 16:56:04,202 INFO [BaseLocalProxyFactory] Bound EJB LocalHome 'CommandServiceBean' to jndi 'java:ejb/CommandServiceBean' | 16:56:04,250 INFO [ProxyFactory] Bound EJB Home 'CommandServiceBean' to jndi 'ejb/CommandServiceBean' | 16:56:04,274 INFO [BaseLocalProxyFactory] Bound EJB LocalHome 'TimerServiceBean' to jndi 'local/TimerServiceBean@14694596' | Early next week, I'll try to integrate the enterprise tests in the hudson matrix http://jbpm.dyndns.org/jbpmwiki/index.php?title=JBPM3HudsonSetup View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4173361#4173361 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4173361

16 years, 4 months

1
0
0 / 0

[Design of JBoss Transaction Services] - Re: ClientUserTransaction and TxPropogation inefficiencies

by adrian＠jboss.org

"jhalliday" wrote : > The ClientUserTransaction is only a proxy to a real transaction on the server so JTS is irrelevant for normal clients | | Unfortunately not. If a normal (i.e. without ORB) client is using UT to communicate to a server and that server is switched from the JTA to the JTS, the client will break. Of course that may be a bug rather than a design issue. | | Then there is the question of what the behaviour should be when the client is using RMI/IIOP rather than JRMP for transactional calls to the server. Should it need the JBossTS libraries, or should it continue to use UT? What if it wants to switch to JBossTS? Using either the JTA API or the CORBA API for transaction demarcation. So you're saying the TPC obtained by UserTransactionSessionImpl is not usable by the client when JTS is installed on the server? | public Object begin(int timeout) | throws RemoteException, | NotSupportedException, | SystemException | { | TransactionManager tm = getTransactionManager(); | // Set timeout value | tm.setTransactionTimeout(timeout); | // Start tx, and get its TPC. | tm.begin(); | Object tpc = getTPCFactory().getTransactionPropagationContext(); // HERE !!!! | // Suspend thread association. | Transaction tx = tm.suspend(); | // Remember that a new tx is now active. | activeTx.put(tpc, tx); | // return the TPC | return tpc; | } | In that case, it is a bug. We probably need some new api to differentiate the two use cases of getTPC(). 1) When propogating calls to other servers 2) When retrieving a TPC usuable by a client to control UTs. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4173359#4173359 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4173359

16 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Management operation over JBM 2 Core API

by timfox

"jmesnil" wrote : | Yes, we still need them to create the destination and the (temp) queue which is used to receive the management messages Seems a bit odd. If we have a standard management destination this shouldn't be necessary surely? Also the SessionBindingQueryRequest/Response and SessionBindingQueryRequest/Response should be defunct now, right? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4173358#4173358 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4173358

16 years, 4 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Thread usage in AIO layer

by timfox

"clebert.suconic(a)jboss.com" wrote : If the file.close takes a lot of time to finish (more than what it would take to write a whole new file), the server will wait until a new file is opened. | To clarify: You're saying the move to next file would currently block until the old file could be closed? anonymous wrote : | But from what I have seen on my tests TimeCompletion < TimeWrite, i.e. by the time a new file is required you will already have a new file opened. | what means this condition shouldn't happen under regular circumstances. | | That's why I think this is not an issue. Yes it's unlikely, but it's possible and therefore is an issue. Anything that might happen, however unlikely we must handle, rather than just barf. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4173355#4173355 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4173355

16 years, 4 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums August 2008