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

[Design of JBoss jBPM] - Re: Any possibility of persistence-API?

by alex.guizar＠jboss.com

Indeed. JPA should be the intersection. I missed the Hibernate, JPA, iBatis bit. An abstraction layer on top of JPA would be a crime :-) We agreed on JPA back in Antwerp if I recall correctly. No mention was made about who or when, tough. I would not mind, but the short term priorities are elsewhere. In any case it has to be there before GA, otherwise it will be impossible to switch later. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204406#4204406 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204406

17 years, 2 months

1
0
0 / 0

[Design of JBoss Labs] - Re: Broken link: http://www.jboss.org/wise/downloads/0.9/0.9

by maeste

oki, fixed. Why don't use 1.0 version? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204397#4204397 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204397

17 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Adding metadata locations in real deployers

by scott.stark＠jboss.org

I don't think the usage had come up yet. Relying on modifiable return values is not a good api. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204396#4204396 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204396

17 years, 2 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Any possibility of persistence-API?

by camunda

But it should be JPA, not a own abstraction... And I think it was agreed to use JPA in jbpm 4 unless we find any real showstopper? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204391#4204391 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204391

17 years, 2 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Any possibility of persistence-API?

by alex.guizar＠jboss.com

anonymous wrote : the api would have to be reduced to the intersection of what hibernate, jpa, ibatis and all other potential persistent stores would offer. Tom, do we really need anything else than the intersection in jBPM 4? Even Seam manages to do with JPA only... anonymous wrote : it would be impossible to do the QA on a matrix of JDK, DB and persistence framework [/quote | Totally true, but we open the door for other folks to do their QA on something other than Hibernate. In jBPM 3 it is just impossible to replace Hibernate without rewriting half of the product. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204390#4204390 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204390

17 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: Using temp at undeploy

by alesj

I did some initial impl under this JIRA: - https://jira.jboss.org/jira/browse/JBDEPLOY-154 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204384#4204384 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204384

17 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: MutableClassInfo?

by stale.pedersen＠jboss.org

ok, after some days trying different approaches for the mutable design here is some of the first ideas (ive removed the javadoc to reduce the size of the code): public interface MutableClassInfo extends ClassInfo | { | | MutableMethodInfo createMutableMethod(Body body); | | MutableMethodInfo createMutableMethod(ModifierInfo modifier, String name, | String[] parameters, String[] exceptions); | | MutableMethodInfo createMutableMethod(ModifierInfo modifier, String name, Body body, | String[] parameters, String[] exceptions); | | MutableMethodInfo createMutableMethod(ModifierInfo modifier, String name, | MutableClassInfo[] parameters, MutableClassInfo[] exceptions); | | MutableMethodInfo createMutableMethod(ModifierInfo modifier, String name, Body body, | MutableClassInfo[] parameters, MutableClassInfo[] exceptions); | | | MutableConstructorInfo createMutableConstructor(Body body); | | MutableConstructorInfo createMutableConstructor(ModifierInfo modifier, String[] parameters, | String[] exceptions); | | MutableConstructorInfo createMutableConstructor(ModifierInfo modifier, Body body, | String[] parameters, String[] exceptions); | | void addMethod(MutableMethodInfo mmi); | | void removeMethod(MutableMethodInfo mmi); | | void addConstructor(MutableConstructorInfo mci); | | void removeConstructor(MutableConstructorInfo mci); | | } | public interface MutableMethodInfo extends MethodInfo | { | | void setModifier(ModifierInfo mi); | | void setReturnType(String returnType); | | void setReturnType(MutableClassInfo returnType); | | void setName(String name); | | void setBody(Body body); | | void setParameters(String[] parameters); | | void setParameters(MutableClassInfo[] parameters); | | void setExceptions(String[] exceptions); | | void setExceptions(MutableClassInfo[] exceptions); | | /** | * TODO: something similar to CtBehavior.instrument(...) | * | * @param mmc | */ | void executeCommand(MutableMethodInfoCommand mmc); | } | public interface MutableConstructorInfo extends ConstructorInfo | { | | void setModifier(ModifierInfo mi); | | void setBody(Body body); | | void setParameters(String[] parameters); | | void setParameters(MutableClassInfo[] parameters); | | void setExceptions(String[] exceptions); | | void setExceptions(MutableClassInfo[] exceptions); | | } | public interface Body | { | String getBody(); | } | // There are three implementations of AbstractJavassistBody | // Default, InsertBefore, InsertAfter (to reflect javassist api) | public abstract class AbstractJavassistBody implements Body | { | String body; | | AbstractJavassistBody(String body) | { | this.body = body; | } | public String getBody() | { | return body; | } | | abstract void createBody(CtBehavior behaviour); | } The idea is that JavassistTypeInfo now will implement MutableClassInfo instead of ClassInfo. The usage of the Class parameter needs to be removed, internal methods using it will just use the CtClass object. The question is the method getType(), can we just remove it altogether? -its been marked as deprecated. JavassistMethodInfo will implement MutableMethodInfo and JavassistConstructorInfo will implement MutableConstructorInfo the same way as JTI. Is there a reason why the JMI constructor is public? if not it should be set to package protected. We need functionality to get the method signature from a method. This could be implemented in a utilclass, but i would rather see it added to the MethodInfo interface. We might also need a method like ClassInfo.getClassLoader(), but i guess Kabir/Adrian know more about that. I havent listed up any exceptions yet. There are a few exceptions, but they all extend RuntimeException so they are not listed. I have no big objections of having them extend Exception instead... Design for fields will be posted later, but they will follow the same idea. Javassist have a lot of functionality to create new methods/constructors/etc that i dont think we need to support directly in MCI, but rather create some util classes to do that. Im thinking of classes/methods like: CtNewMethod.copy/abstractMethod/getter/setter/delegator/etc. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204378#4204378 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204378

17 years, 2 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Any possibility of persistence-API?

by brittm

anonymous wrote : Maybe I get you wrong, but this is exactly what jbpm can do if you use the JtaDbPersistenceServiceFactory, or where is the problem with that solution? My apologies, I wasn't very clear. With JtaDbPersistenceServiceFactory the Hibernate transaction is enlisted in the greater XA transaction that was started by JPA, but the Hibernate transaction is still a new "sub" transaction in a new thread with a new DB connection. However, to work, the solution would have to ensure that jBPM's persistence mechanism is using the actual DB connection that was opened from JPA, so that Hibernate and JPA are using the same DB connection. Using the same DB connection is actually what enables the DB to avoid the deadlock scenario. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204365#4204365 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204365

17 years, 2 months

1
0
0 / 0

[QA of JBoss Portal] - JBoss portlet support for different widgets

by dharam_agrawal

Does JBoss provide APIs to expose portlets as widgets other than iGoogle. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204360#4204360 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204360

17 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Generated Classes not found if they do not match any of

by kabir.khan＠jboss.com

I have added a test showing this behaviour http://fisheye.jboss.com/changelog/JBossAS/projects/jboss-cl/trunk?cs=83351 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204359#4204359 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204359

17 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 2009