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

[Design of JBoss jBPM] - Re: JBPM_LOG issue

by kukeltje

is your config file being used? try to deliberately corrupt it to check View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4070435#4070435 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4070435

16 years, 9 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: JBPM_LOG issue

by shalabh_arora

Any luck on this? I have entry, as mentioned by you, in my jbpm.cfg.xml. Still not seeing anything in log. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4070379#4070379 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4070379

16 years, 9 months

1
0
0 / 0

[TODO - DEVELOPMENT] - jbpm-jpdl-3.2.GA - Scheduler Service not working

by shalabh_arora

Hi, I have configured my jbpm.cfg.xml for scheduler as : I have been able to succesfully deploy jbpm-enterprise.ear in JBoss. When I use timer in my process definition, it adds correctly to JBPM_ACTION table (TIMER_NAME) . But somehow it is not firing the timer. I am able to succesfully run timer with the same process definition in starters kit. Am i missing while trying to deploy on JBoss 4.2.0 GA? Regards Shalabh View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4070378#4070378 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4070378

16 years, 9 months

1
0
0 / 0

[Design of JBoss Build System] - Re: JDK 1.4 Compatibility for Microcontainer and other Proje

by pgier

In maven terms the equivalent to doing this at the module level, I think would be having different artifactIds. So you could have jbossws and jbossws-jdk14 as separate artifactIds. Or at the groupId level, you would have something like org.jboss.jboss-test and org.jboss-jdk14.jboss-test. A couple of issues I see with this in terms of how maven does things: You would have two separate sets of dependencies because maven would treat these as completely separate projects. But it probably wouldn't be that difficult to do. Another problem would be deploying the separate artifacts. Maven profiles do not allow you to change the groupId or artifactId. So I think you would need to have a separate pom.xml, so you would have some duplication of work there. Having a separate pom.xml could be used in addition to having a separate repository. It basically would replace the use of a profile to determine deployment location and whether to run the retro-translation. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4070323#4070323 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4070323

16 years, 9 months

1
0
0 / 0

[Design of JBoss Build System] - Re: JDK 1.4 Compatibility for Microcontainer and other Proje

by ryan.campbell＠jboss.com

Not sure I completely understand the maven issues, but we have handled this in the past with just using the "classifier" at the module level instead of the artifact level. So we had jbossws and jbossws14. Perhaps it would have been better to call it -jdk14. So my question is, is it possible to solve this some place *between* the repository and artifact levels, like in the group name? Or is my maven ignorance starting to show? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4070314#4070314 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4070314

16 years, 9 months

1
0
0 / 0

[Design of JBoss Build System] - JDK 1.4 Compatibility for Microcontainer and other Projects

by pgier

I'm working on setting up jdk1.4 unit tests for microcontainer, and I've run into some issues that would be good to discuss. The first idea that I had was to use a classifier to generate jdk1.4 compatible artifacts and store them in the repository. So the jboss test project (a dependency of microcontainer tests) would generate an artifact with a -jdk14 classifier and look something like jboss-test-jdk14.jar and live next to the jdk5 artifact in the repository. Then projects that want to use the jdk14 version of jboss-test would specify the dependency with the "jdk14" classifier. There are a couple of problems with this model: One is that artifacts with classifiers do not get the same dependency management as the main project artifact. So there is no concept of transitive dependencies for these artifacts. Another issue is that there are a lot of released artifacts that do not currently have jdk14 compatible versions. So there is no compatible artifact that can be used by the jdk14 microcontainer tests. So what I'm thinking about now is having a separate repository for jdk14 compatible jars. Basically it would sit next to the maven2 repository on repository.jboss.org and snapshots.jboss.org. So we'd have something like http://snapshots.jboss.org/maven2-jdk14. Projects could be built and deployed to this repository using a jdk14 profile that will retro-translate the classes, jar them up, and deploy to the jdk14 repository. Then when we want to run the microcontainer jdk14 tests, we just depend on this repository instead of the default one. One issue with this is the problem of where do we get jdk14 versions of our existing jar dependencies if the project has already been released without those jars? For this, I'm working on a feature of the maven-jboss-retro-plugin that will pull a specified project version from the repo, retro translate it, and deploy it to the jdk14 repo. Anyway, I'm looking for any feedback about whether this plan sounds reasonable, or is there a better/easier way to do all this? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4070306#4070306 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4070306

16 years, 9 months

1
0
0 / 0

[Design of JBoss ESB] - Re: MessageType design

by tcunning

I think I agree with Kurt on CommandMessage - I'm not sure it really has to be a special type of ObjectMessage. For the stats gathering, I think we were planning on excluding all CommandMessages from the counts - basically because there's the potential for them to skew the statistics a great deal. We're going to have to check each Message to see if it is a CommandMessage, so whatever allows you to determine that should be pretty lightweight, especially if there are a lot of Messages being processed by the ESB. Is isCommandMessage going to be fast enough? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4070297#4070297 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4070297

16 years, 9 months

1
0
0 / 0

[Design of JBoss ESB] - MessageType design

by kurt.stam＠jboss.com

It looks like we copied the JMS message types of: BytesMessage, MapMessage, ObjectMessage, StreamMessage and TextMessage I see the following issues with the current implementation: 1. There are no interfaces for them in our implementation, so our Message will not actually 'be' one of these types. You'll have to do Message.getPayload() and then figure out what type this it by using getInstanceOf(). 2. We have left the old body implementation, so we have a body and a payload-body as I understand it. This is confusing. I mean I can still do msg.getBody.add("kurt", "Stam") and ignore the new payload stuff. 3. CommandMessage is listed at the same level as BytesMessage, but I think a CommandMessage is more at the ESB logical level. It has nothing to do with the implementation of the message. Maybe we can simple add a Message.property of MESSAGE_TYPE for this? No need to have a different API for this type of message. Maybe I'm missing something. --Kurt View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4070277#4070277 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4070277

16 years, 9 months

1
0
0 / 0

[Design of Persistence on JBoss] - Dynamic data sources with EntityManager

by wiberto

I have an application where the data source it uses is saved in the database. This is because each user can have its own data source. So UserA will have an entry in it's user information table that says to use data source jdbc/UserA. Lets assume that this entry is already configured in the app server itself. How do I tell the EntityManager at runtime to use that datasource. If this was a static configuration I know I will have the persistence unit defined in my persistence.xml file and I would set the annotation in my entity. Something like this | @PersistenceContext(unitName="userAunit") | private EntityManager em; | So how do I make this generic? Do I need to override any EntityManager API to be able to select the unitName at run time? Also, can I create persistence units on the fly? Thanks in advanced, Jose View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4070240#4070240 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4070240

16 years, 9 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Need a NamedObject SimpleMetaType

by scott.stark＠jboss.org

Since Name does not convey the additional requirements, maybe the property type should just be String and the fact that its a reference along with constraints provided via the ManagementObjectRef annotation. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4070205#4070205 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4070205

16 years, 9 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 August 2007