[Design of JBoss jBPM] - iCalendar wrapper
by aapthorp
On Koen's recommendation I'm cross posting from my original post on the user forum:
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=131078
I've been exploring the possibilities of leveraging typical PIM / calendar client functionality to manage user task lists assigned through BPM tools such as jBPM using the iCalendar standard. Initially this is to notify users of task assignments via .ics e-mail attachments and to accept or decline a task. In addition to this is a query capability that allows http access from a calendar agent.
I now have this basic functionality prototyped around jBPM with mapping between taskInstance fields and iCalendar VTDO properties. As per my original post there are a few properties with no obvious equivalents in jBPM (e.g. location and scheduled start time) and am using process variables for these for now. The jBPM console URL to the task is sent in the invitation allowing the user to open the specific task instance.
I'm currently testing using the Zimbra mail server, KDE Kontact and Mozilla lightning which have varying degrees of compliance to iCalendar RFC 2445. Going beyond this would be mobile useage, but haven't explored this yet.
Further down the line I'd like to explore extension of the user agents to handle task specific functionality.
I'd be happy to post the query servlet with mapping to progress this and align on the correct mappings between iCalendar and TaskInstance...potentially identifying extensions to jBPM??? I originally based the iCalendar mailer on the current jBPM Mail class but found that this wasn't sufficiently extensible for MIME attachments, so this may need looking at again.
Cheers
Adrian
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4135469#4135469
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4135469
18 years, 1 month
[Design of JBossCache] - Re: Fqns containing just Strings
by jason.greene＠jboss.com
After discussing this with Brian, I agree with his position, that we should not force Fqns to be String only. The primary reason is that an Fqn is the definitive key of a node in the cache . Further, the node is the definitive notion of an "entity" in a domain model. While it makes things easier for us to restrict Fqns to strings, all we are really doing is pushing the problem onto users, and all of the possible solutions are not nearly as effective as the solution today.
So I propose we look at this from a different perspective, accept that an Fqn must represent multiple Java types, and solve the remaining issues with that prerequisite in mind.
The key issues are:
| * Generic type information is wrong and leads to issues (wrong constructor is sometimes called)
|
| We can solve this problem by just removing the generic info. Generics is just not capable of representing an Fqn, since it has an unbounded number of components that are not guaranteed to represent the same type.
|
| * Fqn's and Strings are not reflexive (Fqn.fromString(fqn.toString()) is not guaranteed to work)
|
| This issue leads to a lot of confusion and misuse of the API. I believe the solution support reflexiveness by adding a getEncodedString(). This method would produce an encoded string that could be used with Fqn.fromString() to produce an equivalent fqn (Fqn.fromString(fqn.getEncodedString()).equals(fqn)). This, of course, means encoding type information for non-string types, and adding proper escaping. Special light-weight encoding would be used for known types, with encoded java serialization as the fallback. This means component types in an Fqn must all be Serializable.
|
| Fqn.toString() would remain the same (normal Java semmantics), to allow for pretty printing.
|
| * Performance in equals()
|
| We can introduce something similar to String.intern() with Fqns. This can be implemented by just having a hash map whose key and value is the single true Fqn instance. Equivalent but non-identical fqns will resolve correctly, due to the collections contract. However, identical fqns will resolve quickly since the object identity test short circuits the full comparison.
|
| * Marshalling Fqns with user defined types (requires marshaling the region fqn first)
|
| This is solved by just having a clear requirement that regions can only use FQNs that are made up of types in the jboss cache classloader.
|
| * Cacheloaders rely on Fqn.toString()
|
| This is solved by fixing the reflexiveness problem. They can use the encoded string instead of the pretty print string.
|
So to summarize, I believe these are the changes we should make:
| * Remove generics from Fqn API
| * Enforce all Fqn components to be Serializable
| * Introduce Fqn.getEncodedString
| * Update cache loaders to use the encoded string
| * Update documentation
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4135453#4135453
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4135453
18 years, 1 month
[Design of AOP on JBoss (Aspects/JBoss)] - Re: Implementing JAXB style parsing for aop-mc-int
by kabir.khan＠jboss.com
As mentioned here http://www.jboss.com/index.html?module=bb&op=viewtopic&t=131367 I have implemented the xsd:refine stuff for bean-deployer_2_0.xsd.
This schema reuses the jboss-beans-common_2_0.xsd as follows (bean-deployer_2_0.xsd and jboss-beans-common_2_0.xsd live in the same folder):
| <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
| targetNamespace="urn:jboss:bean-deployer:2.0"
| xmlns="urn:jboss:bean-deployer:2.0"
| elementFormDefault="qualified"
| attributeFormDefault="unqualified"
| version="1.0">
|
| <xsd:redefine schemaLocation="jboss-beans-common_2_0.xsd">
| <xsd:complexType name="beanType">
| <xsd:complexContent>
| <xsd:extension base="beanType"/>
| </xsd:complexContent>
| </xsd:complexType>
| ...
| </xsd:redefine>
| <xsd:element name="deployment" type="deploymentType">
| ...
| </xsd:element>
|
| <xsd:complexType name="deploymentType">
| ...
| <xsd:choice minOccurs="0" maxOccurs="unbounded">
| ...
| </xsd:choice>
| <xsd:attribute name="name" type="xsd:string" use="optional"/>
| <xsd:attribute name="scoped" type="xsd:boolean" use="optional"/>
| <xsd:attribute name="mode" type="controllerModeType" use="optional"/>
| </xsd:complexType>
|
| <xsd:element name="bean" type="beanType"/>
|
| <xsd:element name="beanfactory" type="beanfactoryType"/>
|
| <xsd:element name="lazy" type="lazyType"/>
|
| </xsd:schema>
|
This seems to work, all the kernel tests are passing.
Now when I try to do the same thing from my aop-beans_1_0.xsd I get an error:
| org.jboss.xb.binding.JBossXBException: Failed to parse source: file:/C:/cygwin/home/Kabir/sourcecontrol/microcontainer/aop-mc-int/target/tests-classes/org/jboss/test/microcontainer/beans/test/AspectSimpleAopTestCase.xml@9,99
| at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:177)
| at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:139)
| at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:147)
| at org.jboss.test.kernel.junit.MicrocontainerTestDelegate.deploy(MicrocontainerTestDelegate.java:294)
| at org.jboss.test.kernel.junit.MicrocontainerTestDelegate.deploy(MicrocontainerTestDelegate.java:438)
| at org.jboss.test.aop.junit.AOPMicrocontainerTestDelegate.deploy(AOPMicrocontainerTestDelegate.java:76)
| at org.jboss.test.kernel.junit.MicrocontainerTestDelegate.setUp(MicrocontainerTestDelegate.java:83)
| at org.jboss.test.aop.junit.AOPMicrocontainerTestDelegate.setUp(AOPMicrocontainerTestDelegate.java:60)
| at org.jboss.test.AbstractTestSetup.setUp(AbstractTestSetup.java:63)
| at junit.extensions.TestSetup$1.protect(TestSetup.java:18)
| at junit.framework.TestResult.runProtected(TestResult.java:124)
| at junit.extensions.TestSetup.run(TestSetup.java:23)
| at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
| at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
| at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
| at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
| at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
| at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
| Caused by: java.lang.StackOverflowError
| at java.lang.String.indexOf(String.java:1352)
| at java.net.URLStreamHandler.parseURL(URLStreamHandler.java:127)
| at sun.net.www.protocol.file.Handler.parseURL(Handler.java:50)
| at java.net.URL.<init>(URL.java:596)
| at java.net.URL.<init>(URL.java:464)
| at sun.misc.URLClassPath$FileLoader.getResource(URLClassPath.java:881)
| at sun.misc.URLClassPath$FileLoader.findResource(URLClassPath.java:871)
| at sun.misc.URLClassPath.findResource(URLClassPath.java:142)
| at java.net.URLClassLoader$2.run(URLClassLoader.java:362)
| at java.security.AccessController.doPrivileged(Native Method)
| at java.net.URLClassLoader.findResource(URLClassLoader.java:359)
| at java.lang.ClassLoader.getResource(ClassLoader.java:977)
| at org.jboss.util.xml.JBossEntityResolver.loadClasspathResource(JBossEntityResolver.java:521)
| at org.jboss.util.xml.JBossEntityResolver.resolvePublicID(JBossEntityResolver.java:329)
| at org.jboss.util.xml.JBossEntityResolver.resolveEntity(JBossEntityResolver.java:259)
| at org.jboss.xb.binding.sunday.unmarshalling.DefaultSchemaResolver.getInputSource(DefaultSchemaResolver.java:443)
| at org.jboss.xb.binding.sunday.unmarshalling.DefaultSchemaResolver.resolveAsLSInput(DefaultSchemaResolver.java:419)
| at org.jboss.xb.binding.Util$1.resolveResource(Util.java:468)
| at org.apache.xerces.util.DOMEntityResolverWrapper.resolveEntity(Unknown Source)
| at org.apache.xerces.impl.XMLEntityManager.resolveEntity(Unknown Source)
| at org.apache.xerces.impl.xs.XMLSchemaLoader.resolveDocument(Unknown Source)
| at org.apache.xerces.impl.xs.traversers.XSDHandler.resolveSchema(Unknown Source)
| at org.apache.xerces.impl.xs.traversers.XSDHandler.constructTrees(Unknown Source)
| at org.apache.xerces.impl.xs.traversers.XSDHandler.constructTrees(Unknown Source)
| at org.apache.xerces.impl.xs.traversers.XSDHandler.constructTrees(Unknown Source)
| at org.apache.xerces.impl.xs.traversers.XSDHandler.constructTrees(Unknown Source)
| at org.apache.xerces.impl.xs.traversers.XSDHandler.constructTrees(Unknown Source)
| at org.apache.xerces.impl.xs.traversers.XSDHandler.constructTrees(Unknown Source)
| at org.apache.xerces.impl.xs.traversers.XSDHandler.constructTrees(Unknown Source)
| at org.apache.xerces.impl.xs.traversers.XSDHandler.constructTrees(Unknown Source)
| at org.apache.xerces.impl.xs.traversers.XSDHandler.constructTrees(Unknown Source)
| at org.apache.xerces.impl.xs.traversers.XSDHandler.constructTrees(Unknown Source)
| at org.apache.xerces.impl.xs.traversers.XSDHandler.constructTrees(Unknown Source)
|
The trigger for this seems to be the inclusion of something in the aop-beans.xsd. In other words, if I uncomment either the xsd:import or the xsd:redefine it falls over with the error seen. If left commented out it passes this stage, but since I've got rid of most elements from the schema to isolate this error it fails when it comes to doing the parsing.
| <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
| targetNamespace="urn:jboss:aop-beans:1.0"
| xmlns="urn:jboss:aop-beans:1.0"
| xmlns:mc="urn:jboss:bean-deployer:2.0"
| elementFormDefault="qualified"
| attributeFormDefault="unqualified"
| version="1.0"
| >
|
| <!-- xsd:import namespace="urn:jboss:bean-deployer:2.0"/-->
|
| <!-- xsd:redefine schemaLocation="jboss-beans-common_2_0.xsd">
| <xsd:simpleType name="classNameType"/>
| </xsd:redefine -->
|
| ...
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4135451#4135451
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4135451
18 years, 1 month