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

[Design of JBoss jBPM] - jBPM for game development?..

by marhatta

Hello I'm interested in developing online card games. Is it possible to use jBPM for this purpose (if the game is step-by-step)? are there any examples? or can you recommend any alike technologies? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205587#4205587 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205587

15 years, 3 months

1
0
0 / 0

[Design of EJB 3.0] - Re: jboss_5_0.xsd: jboss version attribute

by wolfc

I don't get that last bit. getEjbVersion() is returning the EJB spec version, right? Then that should be reflected in the xsd. I agree that version should be controlled by jboss-metadata. I'm not so sure whether it should reflect the AS version though, because we're going to use the same thing in Embedded and Reloaded. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205586#4205586 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205586

15 years, 3 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Enhancing demand

by adrian＠jboss.org

demand was originally part of a pair with supply that let you do a sort simple aliasing. Since the supplys where only known at "Installed", the target state was irrelevant. As it happens, you can use demand to reference other things besides supplys and they could have other states. So you could add it, but it wouldn't work for supplys. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205585#4205585 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205585

15 years, 3 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: BPMN in jbpm4

by brittm

That's a good explanation Tom. Much appreciated. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205583#4205583 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205583

15 years, 3 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Comments in code about large message replication

by timfox

I don't get it. You got expiry queue, dlq to work with large messages and replication didn't you? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205582#4205582 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205582

15 years, 3 months

1
0
0 / 0

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

by scott.stark＠jboss.org

"alesj" wrote : lthough like (c) item states, it won't always work. | How was this dealt in previous 4.x version? | I guess temp resources produced 'temp' urls. Yes, all nested elements were unpacked and had temp urls. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205580#4205580 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205580

15 years, 3 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Comments in code about large message replication

by clebert.suconic＠jboss.com

I removed it, you will only see your original FIXME now: | private ServerMessage makeCopy(final MessageReference ref, final boolean expiry) throws Exception | { | ..... | // FIXME - this won't work with replication!!!!!!!!!!! | long newMessageId = storageManager.generateUniqueID(); | | ServerMessage copy = message.copy(newMessageId); | .... | } | | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205577#4205577 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205577

15 years, 3 months

1
0
0 / 0

[Design of EJB 3.0] - Re: jboss_5_0.xsd: jboss version attribute

by alex.loubyansky＠jboss.com

Coming back to this issue. I am going to make the JBossMetaData.getVersion() return the version of the schema, not the EJB version. There is an attribute (@XmlTransient) ejbVersion which returns the EJB spec version. It is currently set during EjbJar and JBoss metadata merge and in JBoss50Creator. If there needs to be a schema element or attribute to specify the EJB spec version in the JBoss descriptor or annotation then please open a Jira issue. Thanks. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205564#4205564 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205564

15 years, 3 months

1
0
0 / 0

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

by alesj

"adrian(a)jboss.org" wrote : | This avoids also trivially allows you to avoid unpacking them again, since you can ask this cache. | This looks really good :-) since it solves (b), (c) and (d). I'll try to hack some stuff based on this ... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205562#4205562 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205562

15 years, 3 months

1
0
0 / 0

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

by alesj

"adrian(a)jboss.org" wrote : Why are you trying to "destroy" the Deployment object? | I'm not or I'm only destroying it if I created it. As does the ProfileService. "adrian(a)jboss.org" wrote : | All the book keeping for temp data of a VFS file should be inside the VFS itself. | It is. As much as it can be, since temp/modifications were completely left out from initial/original design. "adrian(a)jboss.org" wrote : | I said this before WRT to the horrible explicit VFS Cache you did, but I was ignored. | Where was this? I never (or I must really missed it) heard any idea/feedback about vfs cache. When things were horribly slow, I thought of something. And even then there was no feedback. Good, bad, horrible ... whatever ... it still only has a few lines to change if you wanna ditch that. "adrian(a)jboss.org" wrote : | The "simplist" solution to this problem should be that when somebody creates a root | VFSContext it is against that object that the "temp" information should be stored or at least linked. | | That root VFSContext should always be "live" while somebody holds a | link to the root VirtualFile. | | Then when somebody asks to cleanup a VirtualFile within that context, it can workout which parts of the temp information need to be removed. | | The context should still be usable, its just removed the temp data which would need to be | reconstructed. Which is why close() or destroy() is a bad name/semantic. This makes sense. But it should have been there 2 years ago. :-) All these problems and your suggestions make me wonder if we wouldn't be better off rewriting the whole stuff. Perhaps even moving jar/zip handling to what DML plans to use. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4205561#4205561 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4205561

15 years, 3 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 January 2009