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

[Design of Messaging on JBoss (Messaging/JBoss)] - LinkedList Factor on the Journal...

by clebert.suconic＠jboss.com

On the journal, all the messages from all the destinations are stored on a single journal. Suppose this scenario where a customer is using two destinations: - FastDestination On this destination, a consumer will be aways there to listen to messages - LazyDestination On this destination, a consumer needs to take the action to connect itself (think about e-mails). So he will take days to connect itself again. Adds and deletes are coming for FastDestination but not for LazyDestination. For example, you could have something like that on the journal File1 10 Add Records for Lazy 8000 Add Records for Fast File2 8000 Delete Records for Fast 100 Add Records for Fast File3 100 Delete Records for Fast 300 Add Records for Fast File4 599 Add Records for fast ... On this simple Example... even though all FastRecords from File1, 2 and 3 are gone, the Journal won't be able to reclaim any files until these 10 Lazy records are gone. If Lazy takes for instance 3 days to read its destinations, we will need probably 1 thousand journal files on the journal (or even more). It will be fairly difficult to eventually reload the journal (It would require a lot of memory). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167653#4167653 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167653

17 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: ProfileService equiv to ServiceBindingManager

by bstansberry＠jboss.com

This is going to be a bit of a vague post; mostly just throwing some thoughts out there to see if anything sticks. A con and a pro to the value-factory approach. CON: There's some information loss. The default value (e.g. "1100") is lost to any management tools. [1] PRO: Information consolidation. A management tool can see the actual runtime value for the HAJNDI port. No need to cross-reference over to some PortManager service to figure out the runtime value. I think the pro outweighs the con. But this sounds like the kind of thing the metadata repository is meant to solve, e.g. very similar to Adrian's first post at http://www.jboss.com/index.html?module=bb&op=viewtopic&t=73653&postdays=0... Are we doing anything yet with populating the various levels of the metadata repository? [1] The information loss can be avoided by making the default a property of the "PortManager" bean rather than using the 'default' attribute of the value-factory element. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167603#4167603 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167603

17 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: ProfileService equiv to ServiceBindingManager

by bstansberry＠jboss.com

That's certainly cleaner, both in terms of implementation and in clarity for a user looking at the config file. As for handling mbeans, options in ascending order of effort are: 1) Continue to support the current mechanism where org.jboss.system.microcontainer.ConfigureAction calls into the binding manager. Clunky but supports existing end-user custom mbean services with no change on their end required. 2) Convert mbeans services with ports to pojos w/ @JMX. For our own services, a good thing to do anyway in most if not all cases. 3) Add support for value-factory to the JMX config. Not sure what that entails. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167596#4167596 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167596

17 years, 4 months

1
0
0 / 0

[Design of EJB 3.0] - Delegating all invocations to ejb3-interceptors AbstractCont

by wolfc

For some methods on EJBContext we need to know the invocation context in which we're invoked to actually allow or disallow a request. Right now we analyse not the invocation context, but the security context or transaction context and give the real answer back. For example setRollbackOnly in @PostConstruct on a SFSB runs within the transaction context of the caller, so it works correctly. But the spec defines the transaction context of a lifecycle callback as being unknown, thus it's actually not allowed. So what if we delegate all invocations to ejb3-interceptors AbstractContainer (including the actual injection (instead of field.set etc))? Then ejb3-interceptors always knows the current invocation context. This also means we don't set the current invocation interceptor anymore in aop.xml. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167580#4167580 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167580

17 years, 4 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: login 'unification'

by kukeltje

Heiko, Sorry for the kind of rude tone in my comment in Jira, but there are so many changes and things going one without (at least for what it seems public) discussion that it is very hard to follow things and still have a clear overall picture. I sometimes get the impression that people making changes also have no clear picture, a clear picture of jBPM that is. The fact that you ask what the relation is with the identity module to me is an example of this (no offence). Changes like this login config lead to unnecessary discussions, frustrations if changes are discussed upfront. Ok, now the elaboration. The identity module can be used to do assignments in the workflow engine. There is a kind of 'expression language' that can be used to decide e.g. who should get a task. The default implementation of this uses the database with users, groups, role etc... so when part of this is in files, we either have to duplicate things, keep them in sync or rewrite the identity module to use files (nah... ). The login-config.xml currently uses the same database as identity module, so things are shared and *unified*. Using the database instead of files would solve this, so keeping things as they are... regardless of using a .sar for this. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167565#4167565 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167565

17 years, 4 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: applying the hudson jobs in the sources

by tom.baeyens＠jboss.com

Just for my reference, this topic is related to jira issue http://jira.jboss.org/jira/browse/JBPM-1412 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167557#4167557 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167557

17 years, 4 months

1
0
0 / 0

[Design of JBoss jBPM] - applying the hudson jobs in the sources

by tom.baeyens＠jboss.com

0) do you know any docs that explain the schema of the hudson configuration files ? or do you create them through the web user interface configure page and then copy them from the hudson instance to the source repository ? 1) what do we have to get the hudson jobs defined in the sources configured in an existing hudson instance (like our QA lab) i assume the ant.properties.example and the build.xml has something to do with it. * can that be applied to a running hudson instance ? * can those targets be applied to a hudson instance that has other jobs (like in our QA lab) ? * do you envision an automatic update mechanism that synchronizes the hudson configurations in the sources to the hudson installation ? 2) do you know if it is possible to share this configuration between Bull and JBoss. we would like to have all job configurations in svn, but then Bull and JBoss would each only execute a subset of those configurations on their own QA boxes. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167553#4167553 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167553

17 years, 4 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: login 'unification'

by heiko.braun＠jboss.com

Relax. This is part of the productization and doesn't impact jbpm3. However replacing the actual JAAS login module is trivial. What's the relationship to the identity module? Can you elaborate on this? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167547#4167547 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167547

17 years, 4 months

1
0
0 / 0

[Design of JBoss jBPM] - login 'unification'

by kukeltje

Could someone explain this change to me? I totally miss the reason to switch to property files in combination with keeping the identity module using the database.... Sounds like a bad choice to me. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167544#4167544 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167544

17 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: ProfileService equiv to ServiceBindingManager

by adrian＠jboss.org

A better way of doing this would be to configure it explicitly. Something like: | <bean name="HAJNDI"> | <property name="port"> | <value-factory bean="PortManager" method="getPort" parameter="HAJNDI" default="1100"/> | </property> | ... | The value-factory can be reconfigured to do whatever you want, e.g. use system properties, the binding manager, ldap, etc. All the user has to do is replace the "PortManager" bean. The only problem is that the JMX config doesn't currently support this value-factory style injection. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167542#4167542 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167542

17 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 July 2008