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

[Design the new POJO MicroContainer] - Re: jboss-structure help needed

by scott.stark＠jboss.org

A jboss-structure.xml should not be needed. The problem is that the local login-config.xml resource is not being found preferentially over the conf/login-config.xml. The DynamicLoginConfig service is loading that url: vfsfile:/home/svn/JBossHead/jboss-head/build/output/jboss-5.0.0.Beta4/server/default/conf/login-config.xml and so the custom login config names are all mapping to the default login config, and there are no users/roles.properties found. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122042#4122042 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4122042

18 years, 2 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: Request headers must die

by david.lloyd＠jboss.com

I tried out this change in my local codebase, and by the time I was done I'd eliminated Request and Reply altogether and made the API quite a bit simpler to use (have a look at the updated Context interface). It looked so much nicer that I committed it. Comments welcome. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122014#4122014 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4122014

18 years, 2 months

1
0
0 / 0

[Design of JBossCache] - Re: Data gravitation cleanup process and stale nodes

by bstansberry＠jboss.com

That seems OK, since a member excluded from the view shouldn't be allowed to reappear and begin replicating writes to his old backup trees. I'm with you on not making this configurable. :) Seems like either it's something that works well and we just do it, or there's a problem with the idea and we shouldn't do it at all. The only (end-user) reason I could see for not doing it would be if the presence of an empty node /a/b had some meaning to the application; by removing the node itself we change meaning. But that seems pretty wacky. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122007#4122007 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4122007

18 years, 2 months

1
0
0 / 0

[Design of JBossCache] - Re: Data gravitation cleanup process and stale nodes

by manik.surtani＠jboss.com

Agreed re: making changes when the data owner is still alive. We should assume that session stickiness will be available and gravitation will never occur unless the data owner dies. Which leads on to the first case, of doing such a cleanup after the data owner dies. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4122000#4122000 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4122000

18 years, 2 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Thread dumps generated by triggers/events?

by galder.zamarreno＠jboss.com

http://jira.jboss.com/jira/browse/JBAS-5163 for the thread dump discussion. I'll create a JIRA for the other topic asap. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4121987#4121987 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4121987

18 years, 2 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Another potential enhancement to jbpm

by argo516

Using JMS requires JMS provider which not everybody wants to use. Especially if your application doesn't already use it. For example in our scenario (a distributed application) this would require setting up a central broker, something like ActiveMQ or WebSphere MQ, etc. Obviously, this is a lot of overhead for just getting timers to work. As for my proposal, there's nothing proprietary about it - it simply involves making changes to the SchedulerThread to use proper DB locking (for example using LockMode.UPGRADE_NOWAIT before executing the timer). This will prevent multiple hosts from picking up the same Timer. As to the runtime - I was simply referring to JBPM engine. Instead of relying on servlet.init() to kick start SchedulerServlet, which will only work in J2EE environments, I propose having jbpm itself start the thread. For example, when JbpmConfiguration is initialized it can start the thread. This is not a big deal for us, I was just making a comment since I'm sure there are people who do not run JBPM in J2EE environment. Hope this makes more sense. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4121977#4121977 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4121977

18 years, 2 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Another potential enhancement to jbpm

by koen.aers＠jboss.com

I am afraid I don't understand your problem neither your solution. What do you mean with 'jBPM runtime'? jBPM is a library, there is no runtime unless you write an application that uses the library (such as the servlet that kicks off the SchedulerThread). Also, I don't understand your objections against JMS. To me this sounds like, 'using a JVM is no option because we don't use it, so we decided to write our own proprietary one'... Am I missing something? Regards, Koen View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4121975#4121975 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4121975

18 years, 2 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: Handling of 'deployments taking ~1 minute' scenario

by galder.zamarreno＠jboss.com

http://jira.jboss.com/jira/browse/JBAS-5162 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4121974#4121974 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4121974

18 years, 2 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: JBAS-4228 Preferred master node for HASingleton

by galder.zamarreno＠jboss.com

http://jira.jboss.com/jira/browse/JBAS-5161 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4121973#4121973 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4121973

18 years, 2 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Request headers must die

by david.lloyd＠jboss.com

OK, so a while back we decided that it would be a good idea for requests to contain headers that can be mapped to the headers of the underlying protocol. Now that I'm actually implementing said protocols (HTTP at the moment), it's becoming clear that there is *no* reason to impose a 1:1 correspondence between Remoting requests and requests within the underlying protocol; in fact there are many reasons not to (at least within HTTP). First of all, due to the relatively high overhead of HTTP, it is much more effective to send multiple messages in one request or reply; especially since messages may be quite small individually. This of course is impossible if a single Remoting request demands a single HTTP request. Second, not all Remoting messages correspond to requests. Many messages, such as stream data, or service location messages, can vary in size and frequency as well. Third, in the presence of any protocol in which there are multiple possible channels operating in parallel, it is harder to maintain ordering constraints (in other words, guarantee that message B is processed after message A) when every message must be sent separately, possibly over different connections. When a series of messages are all sent together in a single request, ordering is guaranteed for that group of messages, which will greatly improve latency. Fourth, the actual payload of a Remoting message is a black-box to users. The user cannot reliably perform any higher-level routing or other message manipulation on a finer level than a per session basis anyway. So there's no real benefit to putting extra data outside of the Remoting request itself. Comments? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4121970#4121970 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4121970

18 years, 2 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums January 2008