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

[Design of JBoss jBPM] - Re: jPDL 4 early feedback

by alex.guizar＠jboss.com

The problem with this kind of syntax: <activity type="mail"/> is that you can't define a schema anymore. The content type of the activity element has to allow any element. One solution is to use nested subelements: <activity> | <mail to='boss' /> | </activity> However, this is verbose and makes the process definition less readable. WS-BPEL solved this by having a number of stock activities like: <bpel:invoke operation="selfdestruct" /> and providing a placeholder for extension activities: <bpel:extensionActivity> | <jbpm:mail to='boss' /> | </bpel:extensionActivity> The BPEL approach may be worth considering here. @Heiko: the earlier posts were about skipping validation for user-defined extension items whose schema was unavailable. Just FYI. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4161629#4161629 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4161629

17 years, 3 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: jPDL 4 early feedback

by kukeltje

'the' xsd is not available yet... for the very reason this discussion is taking place.... it has to be defined based on input from us. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4161603#4161603 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4161603

17 years, 3 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: jPDL 4 early feedback

by kukeltje

anonymous wrote : If we cannot extend the schema within minor releases we'll something like this soon: | | | | | | Stock one in 4.0: | | <email/> | | | | Stock one in 4.1: | | <activity class="org.jbpm.activities.FTP"/> | | | | | This already happend in 3. We have a | <mail name="send mail"> | .. | </mail> | and | <node name="esb1> | <action class=org.jboss.soa.esb.services.jbpm.actionhandlers.EsbActionHandler"> | .... (params) | </action> | </node> | | The reason here was that the jBPM and the GPD could be extended by a ESB configuration pane without changing the core... <activity type="FTP"/> should be possible by using 'refs' to generic actionhandlers (sorry, not used to the pvm wordings). Maybe even to generic refs whose implementations are in the core and do not have to be configured in the processdefinition. Still, for me mail, esb etc should not be specific nodes since they are not for the control flow.... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4161602#4161602 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4161602

17 years, 3 months

1
0
0 / 0

[Design the new POJO MicroContainer] - VFS - corrupt ZipFile entries() enumeration on Linux

by mstruk

I'm gonna describe here the root cause of JBVFS-38. The problem is Linux (maybe unix?) specific, and can be reproduced without VFS - the recipe is as follows: 1) Open an existing zip file using JDK's ZipFile object, iterate over entries but don't close the ZipFile. ZipFile zf = new ZipFile(archive); Enumeration enum = zf.entries(); while (enum.hasMoreElements()) { ... } 2) Then, overwrite this zip file with new content using _any_ method (i.e. JarOutputStream, or copy over an existing archive ...) , and properly close it. writeNewJar(archive); 3) Now, open a new ZipFile around this file and iterate over entries. zf = new ZipFile(archive); enum = zf.entries(); while (enum.hasMoreElements()) { ... } Enumeration of entries is corrupt at this point - it returns a non existent entry with a garbled name, real entries are missing. The key to the problem is step 2) - overwriting the _still open_ ZipFile with new content. Interestingly enough, if after step 2) I do a Thread.sleep(30000) and copy the file over with another one through shell, the iteration returns proper content. But no matter how I try to do that as part of the same java process - copying streams, or going so far as to use Runtime.exec("sh -c 'cp file1 file2'") ... no matter what I do, it doesn't help. If ZipFile is closed first, then overwritten, everything is fine. If it's deleted and then recreated, everything is fine as well. I added delete() method to VirtualFile. It delegates the delete all the way to ZipEntryHandler layer - which takes care of releasing locks if necessary - so we can now reliably delete a file, and then reconstruct it, in order to avoid writing over an open file. - marko View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4161593#4161593 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4161593

17 years, 3 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: VFS locking

by scott.stark＠jboss.org

"mstruk" wrote : | In this case I'd say the problem is more with JDK implementation than Windows :) | Which is why we want to move away from the jdk url handler reliance. Its a poor api and has unreliable behavior across platforms. All of the jar/zip file behaviors ultimately rely on native code as well. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4161591#4161591 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4161591

17 years, 3 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: VFS locking

by mstruk

anonymous wrote : so there is a magic flag, after all? There is a flag, but it's not magic :) I've spent a lot of time on this lately. A general rule that works for file: urls (but not for jar:file: urls) is the following: | URLConnection conn = fileUrl.openConnection(); | InputStream in = conn.getInputStream(); | long lastModified; | try | { | lastModified = conn.getLastModified(); | System.out.println("lastModified, "+lastModified); | } | finally | { | in.close(); | } | It's getting and closing the InputStream that does the trick. For jar:file: urls I could only achieve file lock release by triggering finalizers - which means it's pretty useless for anything but tests maybe: | URLConnection conn = jarFileUrl.openConnection(); | conn.setUseCaches(false); | | long lastModified = conn.getLastModified(); | | conn = null; | jarFileUrl = null; | System.gc(); | Thread.sleep(500); | System.gc(); | In this case I'd say the problem is more with JDK implementation than Windows :) - marko View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4161584#4161584 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4161584

17 years, 3 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: jBPM3 switched to maven

by alex.guizar＠jboss.com

I get it now. Thank you for the explanation, Thomas. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4161574#4161574 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4161574

17 years, 3 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: jPDL 4 early feedback

by estaub

Is the XSD itself available? Because it's so much more concise than javadoc, it's easier to see the big picture with the XSD - especially if you have good schema-viewing software. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4161568#4161568 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4161568

17 years, 3 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: jPDL 4 early feedback

by estaub

Is the XSD itself available? Because it's so much more concise than javadoc, it's easier to see the big picture with the XSD - especially if you have good schema-viewing software. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4161567#4161567 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4161567

17 years, 3 months

1
0
0 / 0

[Design of JBoss jBPM] - jBPM3 uses IzPack installer

by thomas.diesler＠jboss.com

http://jbpm.dyndns.org/jbpmwiki/index.php?title=JBPM3BuildingTheInstaller View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4161541#4161541 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4161541

17 years, 3 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums June 2008