June 2007 - jboss-dev-forums - Jboss List Archives

[Design of JBoss jBPM] - Re: Rework of jBPM deployment within JBoss

by david.lloyd＠jboss.com

"tom.baeyens(a)jboss.com" wrote : "david.lloyd(a)jboss.com" wrote : The only change that absolutely requires a deployment of a new version is a change in the graph structure. For any other change, it should be controllable by the user whether a new version is deployed. | | i don't think it's good to have a model that has a complicated calculation on wether or not it will redeploy. It doesn't have to be a complicated calculation. You could use StAX to filter the XML file to remove whitespace and to filter out any elements that are not part of the XML namespace that defines the graph structure, and hash the result of that incrementally. It could actually be more efficient than hashing the whole file because the complicated md5 calculation only takes place over a portion of the data! "tom.baeyens(a)jboss.com" wrote : in development it doesn't matter if you redeploy too much. Agreed. "tom.baeyens(a)jboss.com" wrote : in production you won't update the file that often. Well, yes and no. I might want to update all the deployed processes with new GPD information for example, without causing a new version to be created for every process. Or maybe I want to change other auxiliary information, again using other XML namespaces. "tom.baeyens(a)jboss.com" wrote : so i don't really see a problem with just using a hashcode of the total process archive, preferrably in combination with the timestamp of the file. without inspecting the contents of the deployed process I disagree with the timestamp though. That implies that any change to the file requires a new process version, and I don't believe that this is true. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052350#4052350 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052350

18 years, 10 months

1
0
0 / 0

[Design of JBossCache] - Re: Classloader leak via CacheImpl.invocationContextContaine

by jason.greene＠jboss.com

Ah yes. Perhaps just clearing it is better. Although then it wouldn't survive calls. | cache.getInvocationContext().getOptionOverrides().setCacheModelLocal(true); | cache.put(fqn, key, value); | cache.put(fqn, key, value); | Another option would be to have CacheImpl store a strong reference to every known context, which would go away on cleanup, although this would probably be expensive (at least for creation of the context) Last, we could require that calling code hold the reference (somewhat cryptic, but this is an advanced feature). | InvocationContext ic = cache.getInvocationContext(); | ic.getOptionOverrides().setCacheModelLocal(true); | cache.put(fqn, key, value); | cache.put(fqn, key, value); | -Jason View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052332#4052332 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052332

18 years, 10 months

1
0
0 / 0

[Design of JBoss Build System] - What is this circular dependency issue in common-core?

by scott.stark＠jboss.org

Why is common-core failing to release due to a dependency on itself? | [starksm@succubus common-core]$ mvn release:prepare -DdryRun=true | [INFO] Scanning for projects... | [INFO] Searching repository for plugin with prefix: 'release'. | [INFO] ---------------------------------------------------------------------------- | [INFO] Building JBoss Common Classes | [INFO] task-segment: [release:prepare] (aggregator-style) | [INFO] ---------------------------------------------------------------------------- | [INFO] [release:prepare] | [INFO] Resuming release from phase 'check-dependency-snapshots' | [INFO] Checking dependencies and plugins for snapshots ... | [INFO] ------------------------------------------------------------------------ | [ERROR] BUILD FAILURE | [INFO] ------------------------------------------------------------------------ | [INFO] Can't release project due to non released dependencies : | jboss:jboss-common:pom:2.2.0-SNAPSHOT | in project 'JBoss Common Classes' (jboss:jboss-common-core:jar:2.2.0-SNAPSHOT) | [INFO] ------------------------------------------------------------------------ | [INFO] For more information, run Maven with the -e switch | [INFO] ------------------------------------------------------------------------ | [INFO] Total time: 1 second | [INFO] Finished at: Thu Jun 07 14:26:36 PDT 2007 | [INFO] Final Memory: 11M/170M | [INFO] ------------------------------------------------------------------------ | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052324#4052324 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052324

18 years, 10 months

1
0
0 / 0

[Design of JBossCache] - Re: Classloader leak via CacheImpl.invocationContextContaine

by bstansberry＠jboss.com

Hmm, yeah there is a chance of losing it... cache.getInvocationContext().getOptionOverrides().setCacheModelLocal(true); // gc runs cache.put(fqn, key, value); Call gets replicated. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052318#4052318 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052318

18 years, 10 months

1
0
0 / 0

[Design of JBossCache] - Re: Classloader leak via CacheImpl.invocationContextContaine

by bstansberry＠jboss.com

Yeah, that should work. We pass the context as a param to Interceptor.invoke now, so there is no chance of it getting lost in the middle of a call. Guess solving it's not such a pain. :) Thanks. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052313#4052313 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052313

18 years, 10 months

1
0
0 / 0

[Design of Persistence on JBoss] - SequenceGenerator issue within JPA/Hibernate3 strategy=AUTO?

by asack

So after spending some time with Hibernate3 source and debugging our postgres database (8.1.3), it seems that the PostgresDialect class sets its default IdentifierGenerator to a SequenceGenerator (makes sense since Postgres uses SERIAL types). Now, for EJB3 style @GeneratedId, the default strategy is AUTO which according to the HibernateExt annotation processor dwindles into a "native" which eventually leads the EntityPersister handling these entities (such as the SingleTablePersister) to use the SequenceGenerator. Fine, but when the SequenceGenerator is configured, it creates a sequence called "hibernate_sequence" which is used to basically generate values (1,2,3 so on). It seems to me that if I have all my entities as AUTO then Hibernate3 uses the ONE hibernate_sequence variable to generate primary keys across tables! Is that true? That just seems nuts to me. I would in fact believe that AUTO would turn into SEQUENCE and create a per table, table_column_seq variable to manage primary keys. I've debugged this now over two days since Hibernate3 is new to me. Can someone who is knowledgeable with the source (and not dangerous like myself) comment on my observation? Is this really true? Thanks! PS Wasn't sure if this should go in the Hibernate users group or design but I am technically asking a design question with respect to my user issue! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052311#4052311 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052311

18 years, 10 months

1
0
0 / 0

[Design of JBossCache] - Re: Classloader leak via CacheImpl.invocationContextContaine

by jason.greene＠jboss.com

So why don't we make it a weak ref, and recreate it if its null? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052304#4052304 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052304

18 years, 10 months

1
0
0 / 0

[Design of JBossCache] - Classloader leak via CacheImpl.invocationContextContainer

by bstansberry＠jboss.com

The handling of InvocationContext will leak JBC's classloader. An InvocationContext gets stored in a ThreadLocal and doesn't get cleared. This is by design to avoid creating a new InvocationContext for each request, but it will have the effect of leaking the JBC classloader to whatever threads call into JBC. Note that the fact that CacheImpl.invocationContextContainer is an instance field will not prevent the leak. When the CacheImpl is gc'd, the invocationContextContainer ThreadLocal will be gc'd as well. However, for each thread that invoked on the cache there will still be a ThreadLocal.ThreadLocalMap.Entry whose value field is a strong ref to the InvocationContext. If a particular thread's ThreadLocalMap happens to do some cleanup work (i.e. a rehash) it will detect that that ThreadLocal has been gc'd and expunge the Entry, but to allow the classloader to be gc'ed all such threads would have to do that, which is unlikely. Solving this will be a pain, since clearing the ThreadLocal after each request will likely break a number of subtle things where code calls back into the cache. For example, Notifier would probably have to be changed. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052259#4052259 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052259

18 years, 10 months

1
0
0 / 0

Jboss 5.0

by Jayesh

I am looking for any document on Jboss 5.0 , Looks like the deployment , configuration etc all changed quite dramatically. Does any one know if there is any document which explains what to change from porting jboss 4.0x to jboss 5.0 Regards

18 years, 10 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: Removing dependency on concurrent.jar

by kabir.khan＠jboss.com

It works fine with AOP 2.0. Beyond that I have not done any other tests. The original GUID issue works fine View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052239#4052239 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4052239

18 years, 10 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 June 2007