[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
18 years
[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
18 years
[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
18 years
[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
18 years