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

[Design of JBoss jBPM] - remove .project and .classpath from bpel

by tom.baeyens＠jboss.com

alex, if you don't use the .project and .classpath in the bpel subproject, can you delete those files ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002190#4002190 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002190

19 years, 2 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: committing content from our

by tom.baeyens＠jboss.com

"camunda" wrote : 1.) contribute some jbpm commands (because we had written some additional logic like updating a process version in special cricumstances) to get rid of our own service-classes. | great. put them in org.jbpm.command package. the good thing is that commands are isolated. so you can't break any existing stuff. "camunda" wrote : 3.) Extract the generic code we used for a Swing-Tasklist and opening tasks in Swing panels to form a generic framework for Swing applications working with jBPM | a minimal working swing client would be nice. even better would be a client based on eclipse rcp. ever thought of doing that ? "camunda" wrote : One problem is maybe, that we have some very pragmatic commands in our toolkit (e.g. updating the process version of a running instance in the case, that there is a note with the same name in the new version), which we also want to contribute. Would that be OK for you? | process migration is a good command. providing that functionality is on my todo list as well. i want to do this as follows: input is a processInstance, a new processDefinition and a map of old node names to new node names. any help in that is appreciated. even if your code doesn't yet have the node map integrated. "camunda" wrote : Maybe I can make a package org.jbpm.command.experimental for that? | no need for that. put it in the org.jbpm.package. if you can, such info should be in the documentation. i guess the most practical place to start documenting commands is in the javadocs. "camunda" wrote : A second thing is, that I need for Swing-applications some GetProcess/Task/.../Command's, because I need to preload some parts of the objects graph before give the result to the client. But the advantage is, we can get rid of any DataTransferObject's we currently use in the AdminClient. I will just add them to the core, ok? | yes, please add them. "camunda" wrote : Also I will not have a JUnit test for every command, even if they are working in some real life applications... But I will work on that issue as soon there is time! | as long as the average test coverage is ok, this is good. but beware that writing a test also guards your code of being evicted if you can't maintain it any more. if untested code starts producing problems and you're not around to fix it in a reasonable time, we might decide to evict that code... With unit test we can fix it ourselves, even if you're not around. great plan. thanks. sorry for late reply View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002180#4002180 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002180

19 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Maven build scripts

by alesj

Can I assign you this JIRA issue? - http://jira.jboss.com/jira/browse/JBMICROCONT-117 So that we can also bug you through JIRA if we have some Maven + MC problems. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002145#4002145 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002145

19 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: SerializableDeploymentRepository notions

by scott.stark＠jboss.org

Its done dynamically as part of the deployment processing of the profile. If a DeploymentContext does not have predetermined managed objects its run through the MainDeployer.process to the CLASSLOADER_DEPLOYER and then the profile.updateDeployment so that the attachments can be saved. Its just object serialization of the context attachments object at that point using the serializer associated with the repository. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002139#4002139 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002139

19 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: SerializableDeploymentRepository notions

by bill.burke＠jboss.com

so how are the objects serialized up? Do you precompile? Or will it just do it? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002132#4002132 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002132

19 years, 2 months

1
0
0 / 0

[Design of JBoss internal QA (Test Suite)] - Re: Test suite classpath normalization

by scott.stark＠jboss.org

"ryan.campbell(a)jboss.com" wrote : Ok, so it sounds like you want something like several of these: | | <test-target>.classpath | | where <test-target>.classpath is the ant target with dashes converted to dots. So we would have: | | jboss.all.config.tests.classpath | tests.security.manager.classpath | tomcat.ssl.tests.classpath | etc... | | We will come up with estimates for the monolithic test classpath vs. group level classpaths. The monolithic test classpath will meet our immediate needs, but I realize the group level classpaths provide better documentation and better analysis of depdencies. | Sounds good. "ryan.campbell(a)jboss.com" wrote : | As for the tests in other modules, this goes back to isolating the test harness/refactoring the test suite. This is in scope for the near future, but I'd like to keep that discussion separate. Ok. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002117#4002117 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002117

19 years, 2 months

1
0
0 / 0

[Design of JBoss internal QA (Test Suite)] - Re: Test suite classpath normalization

by ryan.campbell＠jboss.com

Ok, so it sounds like you want something like several of these: <test-target>.classpath where <test-target>.classpath is the ant target with dashes converted to dots. So we would have: jboss.all.config.tests.classpath tests.security.manager.classpath tomcat.ssl.tests.classpath etc... We will come up with estimates for the monolithic test classpath vs. group level classpaths. The monolithic test classpath will meet our immediate needs, but I realize the group level classpaths provide better documentation and better analysis of depdencies. Good point on the server jars, they could be included from ${jboss.dist} as well. As for the tests in other modules, this goes back to isolating the test harness/refactoring the test suite. This is in scope for the near future, but I'd like to keep that discussion separate. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002112#4002112 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002112

19 years, 2 months

1
0
0 / 0

[Design of JBoss internal QA (Test Suite)] - Re: Test suite classpath normalization

by scott.stark＠jboss.org

This is needed, but we should be building more test group specific client classpaths to better track what tests require what jars from the client dir. Note that some tests do rely on server jars at they try to tests implementation details. These tests should be moved into the corresponding module they are testing the implementation of. We are starting to include more tests in modules, so we need a way to run these tests as part of the overall qa tests. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002108#4002108 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002108

19 years, 2 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBWS-1260 - such a part must refer to an element named a

by jason.greene＠jboss.com

"jason.greene(a)jboss.com" wrote : "thomas.diesler(a)jboss.com" wrote : | | Also, this WSDL violates BP 1.0 because it uses "type" on the part definition for a document/literal web service. It must be element. | | | | | | | <part name="attachmentContents" type="xsd:string"/> | | | | | | | Note, this comment is wrong, the AP 1.0 spec allows type or element. BP 1.0 only governs the standard SOAP binding not the MIME binding. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002107#4002107 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002107

19 years, 2 months

1
0
0 / 0

[Design of POJO Server] - SerializableDeploymentRepository notions

by scott.stark＠jboss.org

So the majority of the repository based profile service is in the SerializableDeploymentRepository. This is an implementation of DeploymentRepository that relies on object serialization to store contents on the file system. The serialization is pluggable, so while today its simple java serialization, it could (and will be) jboss serization to an xml file to allow for a better long term storage format. It could be jdbc or something else as well if desired. The repository uses the following locations under the {name} profile root: root/{name}/bootstrap - the bootstrap beans root/{name}/deployers - profile deployers root/{name}/deploy - installed deployments root/{name}/apps - post install deployments root/{name}/attachments - pre-processed deployment metadata attachments root/{name}/profile/edits - admin edits to deployments A DeploymentContext refers to the raw unedited deployment archive/directory, and when a DeploymentContext is processed through the MainDeployer.process(-1, Deployer.CLASSLOADER_DEPLOYER), the profile and by delegation the repository is updated with the parses metadata pojos. What needs to happen is that when a DeploymentContext is loaded from the repository and it has pre-parsed attachments, these are set as the getPredeterminedManagedObjects(). If there are admin edits then the attachments come from the profile/edits override of the attachments. If a DeploymentContext has a non-empty getPredeterminedManagedObjects() attachments, processing should begin at the Deployer.CLASSLOADER_DEPLOYER and all attachment processing is skipped. This check and deployer bypass logic should happen in the MainDeployerImpl. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002106#4002106 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4002106

19 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 2007