[Design of JBoss Transaction Services] - Re: jta/jts jar/config file change
by jhalliday
I'm inclined to make two further changes in respect of the .jar files and config files we ship. To facilitate clean embedding, I would like to:
- bundle the default config file into the .jar and change the existing search algorithm to look for it there as a last resort before giving up. This will allow the system to run without needing the etc dir (or other dir containing the config file) on the classpath, whilst being unobtrusive for existing installations.
- bundle the contents of ext/jbossts-common.jar into the jta/jts jar files directly. The splitting out of the common code made sense when it was consumed by other apps, but with JBossTS as the only user we may as well streamline things.
With those changes it should become possible to use the system just by including a single .jar on the classpath, along with any 3rd party .jars from ext depending on the functionality required.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4232708#4232708
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4232708
15 years, 1 month
[Design of JBoss jBPM] - Super State Node
by swatis
As we can not put "start-state" in super-state node then which node executed first? If it depends on order defined in super-state then Why it is not taking the order which I mentioned in process?
This is piece of code
| <super-state name="super1">
| <process-state name="getPrice">
| <sub-process name="Calculate Price" version="1"></sub-process>
| <variable name="productnumber" access="read,write" />
| <variable name="price" access="read,write" />
| <transition to="Calculate Overall Price"></transition>
| </process-state>
| <node name="Calculate Overall Price">
| </node>
|
| <transition name="" to="Display Cost"></transition>
| </super-state>
One more question if there are two parallel activities in a process-state and no join in the super-state node, then in that case when this super state will be completed? meaning when we can say super-state node completed execution?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4232707#4232707
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4232707
15 years, 1 month
[Design the new POJO MicroContainer] - Uploading MC artifacts to the labs downloads area
by kabir.khan＠jboss.com
I'm working on a script to automate uploading the Microcontainer releases to the labs downloads area. From the comments of the script:
| <!--
| Script to put the releases belonging to the microcontainer project in the downloads on labs.
|
| Properties for this script are set in local.properties.xml:
|
| 'maven.home' contains the root of your maven installation.
|
| 'labs.checkout.folder' should point to a checkout of the jbossmc area of labs,
| svn url: https://cms.labs.jboss.com/prod/forge/portal-content/default/members/jbossmc
|
| Which individual sub-projects to be released are controlled by the version set in
| the 'version.xxx' properties. If you don't want to release a particular sub-project,
| then comment out that version in local.properties.
|
| 'release.checkout.folder' should point to an empty directory, which is where the
| script will check out each individual sub-project release from the subversion repository
| that backs the maven repository.
|
| Some sub-projects are 'complex', i.e. they contain more than one module. These projects
| have a release build to create a zip containing all artifacts. In some cases, whoever is
| publishing the release to maven might have forgotten to publish the whole release artifact.
| In this case the script will check out the whole project, and invoke the release build
| and publish the release zip. If the release build for the project does not exist in the
| subversion repository backing the maven repository, the release tag of the project's
| source will be checked out from subversion and a proper release build will be run.
| 'maven.checkout.folder' should contain the root of where you want the subversion repository
| backing the maven repository to be checked out. It will create the subfolders
| ${maven.checkout.folder}org/jboss/
| if they are not there already, and then checkout each affected individual sub-project's
| area of the maven repository there. E.g.
| http://anonsvn.jboss.org/repos/repository.jboss.org/maven2/org/jboss/micr...
| would be checked out to ${maven.checkout.folder}/org/jboss/microcontainer.
| (The 'complex' projects are jboss-man, jboss-microcontainer, jboss-cl, jboss-deployers).
|
| Once the script has all the required artifacts required, it invokes a custom ant task
| to copy the files to a sub-folder of ${labs.checkout.folder}/downloads per sub-project.
| The ant task also looks for the sub-project's marker in ${labs.checkout.folder}/project.xml
| and updates the downloads section with information about the released files.
| NOTE: The lastModified time of the file is used as the release date, so that might need tweaking
| if this script is run after the actual maven artifacts were initially published.
|
| Finally, an 'svn add' is invoked on the new files in ${labs.checkout.folder}.
|
| Once done, you should verify that what is in ${labs.checkout.folder} looks correct, and then
| manually invoke 'svn commit'.
| -->
|
local.properties:
| #Point to your maven install root
| maven.home=/usr/share/maven/
|
| # Point this to the checkout folder of the jbossmc labs area
| labs.checkout.folder=/Users/kabir/sourcecontrol/labs/jbossmc
|
| # The folder where you want to check out and build the releases from
| release.checkout.folder=/Users/kabir/sourcecontrol/mcrelease
|
| # The folder where you want to check out the subversion repository backing the maven
| # repository for publishing the release zips of 'complex' projects. This is only done
| # if the release artifacts were not added to maven
| maven.checkout.folder=sourcecontrol/thirdparty/maven2
|
| # The versions of the sub-projects you want to release. They must be in the form
| # of the release number, e.g. 2.0.1_GA (luckily this matches the convention for
| # how the releases are tagged for when we need to build the projects).
| # If you do not want to release a particular sub-project, comment out the property
| # for its version
| version.reflect=2.0.2.GA
| version.mdr=2.0.1.GA
| #version.mdrc=
| version.man=2.0.0.GA
| version.microcontainer=2.0.6.GA
| version.cl=2.0.6.GA
| version.deployers=2.0.7.GA
| #version.reliance=XXXXNotThereYet
| version.vfs=2.1.2.GA
| version.mcint=2.2.0.Alpha1
|
It currently only publishes the source and binary artifacts since the javadocs don't seem to be published yet? Once we have the improved javadocs that we talked about in Neuchatel those can be added easily.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4232662#4232662
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4232662
15 years, 1 month
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Jar dependencies chapter
by ataylor
anonymous wrote : 1) We need a section on what jars the user needs on the client and server classpaths, e.g.
|
| If you're using core, you need:
|
| jbm-core-core-client.jar
|
| if you're using netty you need netty.jar
|
| if you're using jms you need jbm-jms-cllient.jar (we should have separate jar for jms *client* stuff)
|
| If you're using log4j you need.. blah blah
+1
anonymous wrote : 3)
|
| We should also take the javax.jms.* interface classes out of jboss-jee.jar and put them in their own jar so the user doesn't have to include *all* the jee classes.
|
| 4) Also I think we should take all the jars that the JBoss MC needs to run, unzip them and rebuild them into another jar jboss-mc.jar (or whatever) and distribute that, this will greatly limit and simplify the number of jars we distribute.
what happened to 2?
makes sense. should we do this in the build, i.e. unzip - zip or is there a better way?
anonymous wrote : 5) jboss-logging.jar has dependencies to both log4j *and* jboss as logging. Is this right? I don't think we should expect users who just want to use log4j to include all the jboss as logging jars!
do you mean jbm-logging.jar or jboss-common-logging.jar?
anonymous wrote : 6) Why are we including jbm-ra.jar in the distro? Isn't jbm-ra.jar sufficient?
Its used when creating the AS profile from the distro.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4232639#4232639
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4232639
15 years, 1 month