February 2009 - jboss-dev-forums - Jboss List Archives

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Configure a queue to be ordering aware

by gaohoward

I agree with your reason. There is one exception, if user wants the ordering of messages to be determined by the time they arrive at the target queue (the time is the machine time that hosting the queue), the ordering has to be calculated on the server. Also if user wants strict ordering from multiple producers, the control has to be at the server side. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206189#4206189 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206189

16 years, 10 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Configure a queue to be ordering aware

by timfox

I would rather just have it configured in the connection factory, not the queue. This means the queue can be used for both ordered and non ordered messages. Also it's more consistent with message grouping in JBM 2.0 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206182#4206182 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206182

16 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Re: Security Deployer assuming VFSDeploymentUnit

by alesj

They also break the api. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206179#4206179 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206179

16 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Re: Security Deployer assuming VFSDeploymentUnit

by dimitris＠jboss.org

I believe the changes break some tests: http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-5.0.x-test... org.jboss.test.jacc.test.FormAuthUnitTestCase(JACC).testFormAuthException org.jboss.test.security.test.WebJASPIFormUnitTestCase(tests-security-basic-unit).unknown org.jboss.test.web.security.GenericHeaderAuthUnitTestCase.testGenericHeaderBaseAuth org.jboss.test.web.test.FormAuthUnitTestCase.testFormAuthException View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206175#4206175 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206175

16 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Re: The DeploymentManager and ProfileService

by emuckenhuber

"scott.stark(a)jboss.org" wrote : | Ok, so an issue with that is how do we store admin edits of such profiles? | I think in this case the Profile itself would need to take care about it, because for a VFSDeployment we can check the metadata paths, if there were modifications and don't apply admin edits. But we don't have a generic way to do that for a normal Deployment. But in the end if we have something like (e.g. in the ManagementView) | removeAttachments(ProfileDeployment d, String attachmentName); | this could also work. "scott.stark(a)jboss.org" wrote : | What's missing is a generic ProfileBootstrap that can have different ways of specifying subprofiles that should be included. For example, the deployers and base services would be specified via criteria, user apps specified via a uri to one or more apps defined in a jboss tools project. I'm going to review the changes in trunk tonight, but it is probably more of a notion of a resolver that I'm thinking of. | Yes there is definitely some work to do on the ProfileServiceBootstrap. Especially the one based on xml needs some more work, if you want to look at that one. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206155#4206155 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206155

16 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Re: The DeploymentManager and ProfileService

by scott.stark＠jboss.org

"emuckenhuber" wrote : | Hmm, there are some use cases where you don't need any repository. | For example the transient application profile managed by the DeploymentManager. | This will be just a hashMap containing the isCopyContent == false deployments, so that they | are also visible in the ManagementView. | But it's still a independent profile, which can be activated / deactivated by the DeploymentManager. | Ok, so an issue with that is how do we store admin edits of such profiles? "emuckenhuber" wrote : | Furthermore i think a VFS/uri does not make up a profile, as you still can could have a different (maybe static) profile, | where you create non-vfs based deployments - this is now also possible with the abstraction of ProfileDeployment (although not fully implemented) | Right, the profiles I'm working on don't have URIs either as they are described in terms of criteria that need to be resolved. "emuckenhuber" wrote : | Although i also think that there is something missing - but more in the sense of a ResourceDiscovery or ProfileSource. | Something where you can share the same source and don't need to maintain the profile root uris in each profile. | Maybe this also matches somehow to the work you want to do with a DeploymentRepository? | | Can you provide some more information and/or use cases why you think this is not enough? | I mean maybe i'm just missing something :) | What's missing is a generic ProfileBootstrap that can have different ways of specifying subprofiles that should be included. For example, the deployers and base services would be specified via criteria, user apps specified via a uri to one or more apps defined in a jboss tools project. I'm going to review the changes in trunk tonight, but it is probably more of a notion of a resolver that I'm thinking of. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206151#4206151 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206151

16 years, 10 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Missing VirtualFile::isFile?

by scott.stark＠jboss.org

"alesj" wrote : | JarHandler/ZipContextHandler::isArchive==true, everybody else == false? Yes, but there could be other archive schemes in the future like tar. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206150#4206150 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206150

16 years, 10 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Configure a queue to be ordering aware

by gaohoward

we can do both ways. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206149#4206149 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206149

16 years, 10 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Deployment cleanup & modifications

by alesj

Thinking about it even more ... "alesj" wrote : | How do you then handle these three calls: | (1) root::getChildren() | (2) root::getChild("myapp.ear/myweb-ui.war/WEB-INF/lib/ui.jar/org/acme/FooBar.class") | (3) VFS::getRoot(new URL("${jboss.deploy}/myapp.ear/myweb-ui.war/WEB-INF/lib/ui.jar/org/acme/FooBar.class")) | | I would expect for (1) not to use temp, otherwise I won't know when my original myapp.ear was deleted. | For (2) and (3) I would like to use all the existing temps I could get in order not to re-unpack something. | I guess this shouldn't be such a huge problem as I see it. :-) If you have a handle to some VirtualFile, use it as it is - be it client view or temp, it's up to the type of the handle. If I get an URL, try to use as much as possible. Hence treating URLs as server side objects. The 'inconsistency' will always be there. e.g. VirtualFile that was fetched via navigation vs. direct URL access "alesj" wrote : | So, during structure recognition, we already get a few unpacked nested jars. | Then it turns out that the user requested this app to be temped. | | To be true to our unpacking/temp performace reasons (= reuse as much as possible), | This is also quite easy to avoid (to some extent). :-) The existing unpack/temp info should just hold the ref to the new File, which should be later on re-used. Here we would still have two versions of wiring, one from client the other from temp, since incorporating re-wiring would perhaps even be wrong. But at least it would be done on the same unpacked/temped copies, hence no need to spend any time doing that. But this two new 'findings' shouldn't stop you from adding some content to this problems. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206131#4206131 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206131

16 years, 10 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Configure a queue to be ordering aware

by timfox

I think a better place to configure this is in the connection factory, not the queue. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206129#4206129 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206129

16 years, 10 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 February 2009