[jBPM] New message: "[org.jbpm.bpel.sublang.xpath.XPathEvaluator] cannot create element for step with non-numeric predicate: [(DefaultNameStep): arg0]"
by Christy Christy
User development,
A new message was posted in the thread "[org.jbpm.bpel.sublang.xpath.XPathEvaluator] cannot create element for step with non-numeric predicate: [(DefaultNameStep): arg0]":
http://community.jboss.org/message/529379#529379
Author : Christy Christy
Profile : http://community.jboss.org/people/christy
Message:
--------------------------------------------------------------
Hi to everybody!
Please help me!
Here is my simple bpel process:
> <process name="HelloWorld" targetNamespace="http://nmsp" xmlns:tns="http://nmsp"
> xmlns:buoysnmsp="http://buoys.ws.esimo/" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> xmlns="http://docs.oasis-open.org/wsbpel/2.0/process/executable">
> <import importType="http://schemas.xmlsoap.org/wsdl/" location="hello.wsdl"
> namespace="http://nmsp"/>
> <partnerLinks>
> <partnerLink myRole="Greeter" name="caller" partnerLinkType="tns:Greeter-Caller"> </partnerLink>
> <partnerLink partnerRole="BuoysRole" name="BuoysWSJaxWsService"
> partnerLinkType="tns:BuoysLink"> </partnerLink>
> </partnerLinks>
>
> <variables>
> <variable messageType="tns:nameMessage" name="request"> </variable>
> <variable type="xsd: int" name="n"> </variable>
> <variable messageType="tns:greetingMessage" name="response"> </variable>
> <variable messageType="buoysnmsp:BuoysWSJaxWs_getIntArr" name="BuoysWSJaxWs_getIntArr"> </variable>
> <variable messageType="buoysnmsp:BuoysWSJaxWs_getIntArrResponse" name="BuoysWSJaxWs_getIntArrResponse"> </variable>
> </variables>
> <correlationSets>
> <correlationSet name="trip" properties="tns:tripLocator"/>
> </correlationSets>
> <sequence name="MainSeq">
> <receive createInstance="yes" name="ReceiveName" operation="sayHello" partnerLink="caller"
> portType="tns:Greeter" variable="request"> </receive>
> <assign>
> <copy>
> <from>1</from>
> <to variable="n"/>
> </copy>
> <copy>
> <from>$request.name/leafElement[$n]</from>
> <to>$BuoysWSJaxWs_getIntArr.getIntArr/arg0[$n]</to>
> </copy>
> <!--</copy>-->
> </assign>
>
> <invoke name="InvokeBuoys" operation="getIntArr" partnerLink="BuoysWSJaxWsService"
> portType="buoysnmsp:BuoysWSJaxWs" inputVariable="BuoysWSJaxWs_getIntArr"
> outputVariable="BuoysWSJaxWs_getIntArrResponse">
> <correlations>
> <correlation set="trip" initiate="yes" pattern="in"/>
> </correlations>
> </invoke>
> <assign>
> <copy>
> <from>$BuoysWSJaxWs_getIntArrResponse.getIntArrResponse</from>
> <to>$response.greeting</to>
> </copy>
> </assign>
>
> <reply name="SendGreeting" operation="sayHello" partnerLink="caller" portType="tns:Greeter"
> variable="response"> </reply>
>
> </sequence>
> </process>
>
This is its wsdl:
> <definitions targetNamespace="http://nmsp"
> xmlns:tns="http://nmsp" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> xmlns:buoysnmsp="http://buoys.ws.esimo/"
> xmlns:bpel="http://schemas.xmlsoap.org/ws/2003/03/business-process/"
> xmlns:plt="http://docs.oasis-open.org/wsbpel/2.0/plnktype"
> xmlns="http://schemas.xmlsoap.org/wsdl/">
> <import namespace="http://buoys.ws.esimo/" location="BuoysWSJaxWsService.wsdl" />
> <types>
> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> targetNamespace="http://nmsp">
>
> <xsd:element name="newElement" type = "tns:newElement" />
>
> <xsd:complexType name="newElement">
> <xsd:sequence>
> <xsd:element name="leafElement" type = "xsd:double" maxOccurs="unbounded"/>
> </xsd:sequence>
> </xsd:complexType>
>
>
> </xsd:schema>
> </types>
> <message name="greetingMessage">
> <part name="greeting" element="tns:newElement" />
> </message>
> <message name="nameMessage">
> <part name="name" element="tns:newElement" />
> </message>
> <portType name="Greeter">
> <operation name="sayHello">
> <input message="tns:nameMessage" />
> <output message="tns:greetingMessage" />
> </operation>
> </portType>
> <plt:partnerLinkType name="Greeter-Caller">
> <plt:role name="Greeter" portType="tns:Greeter">
> </plt:role>
> </plt:partnerLinkType>
> <plt:partnerLinkType name="BuoysLink">
> <plt:role name="BuoysRole" portType="buoysnmsp:BuoysWSJaxWs">
> </plt:role>
> </plt:partnerLinkType>
> <bpel:property name="tripLocator" type="xsd:int" />
> <bpel:propertyAlias propertyName="tns:tripLocator" messageType="buoysnmsp:BuoysWSJaxWs_getIntArr"
> part="getIntArr" />
> <bpel:propertyAlias propertyName="tns:tripLocator" messageType="buoysnmsp:BuoysWSJaxWs_getIntArrResponse"
> part="getIntArrResponse" />
> </definitions>
When I try to invoke it I get the error:
> ERROR [org.jbpm.bpel.sublang.xpath.XPathEvaluator] cannot create element for step with non-numeric predicate: [(DefaultNameStep): arg0]
Why? what is wrong?
> P.S. it is interasting that if I change "to" in <copy>
> <from>$request.name/leafElement[$n]</from>
> <to>$BuoysWSJaxWs_getIntArr.getIntArr/*arg0[$n]*</to>
> </copy>
> to <copy>
>
> <from>$request.name/leafElement[$n]</from>
>
> <to>$BuoysWSJaxWs_getIntArr.getIntArr/*arg0[1]*</to>
>
> </copy>
everything works fine. Where is my mistake?
Thank you!
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/529379#529379
16 years, 1 month
[JBoss Microcontainer Development] New message: "Re: How to migrate AssembledDirectory"
by John Bailey
User development,
A new message was posted in the thread "How to migrate AssembledDirectory":
http://community.jboss.org/message/529374#529374
Author : John Bailey
Profile : http://community.jboss.org/people/johnbailey
Message:
--------------------------------------------------------------
A better long-term approach would be to move to using ShrinkWrap archives to declaratively create ear/war/jar archives. ShrinkWrap already has fluent API to add classes/resources to an archive.
JavaArchive archive = Archives.create("archive.jar", JavaArchive.class)
.addClasses(MyClass.class,MyOtherClass.class)
.addResource("mystuff.properties");
I have also written a VFS3 based filesystem that uses ShrinkWrap archives for a backing. This allows you to take an archive an mount it into the VFS wherever you like. Once mounted you can simply deploy the VirtualFile pointing to the mounted FileSystem.
JavaArchive archive = ...
VirtualFile archiveFile = VFS.getChild("/vfs/path").getChild(archive.getName());
VFS.mount(archiveFile, new ArchiveFileSystem(archive, tempDir));
deploy(archiveFile);
I need to work with Andrew to figure out where the ArchiveFileSystem should live long term, but I do think this is the best long term testing strategy for creation of test archives. Since we are suggesting ShrinkWrap be used for customers to test through embedded, it would be a good idea to do the same where possible. This will also reduce the number of competing implementations of the same functionality.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/529374#529374
16 years, 1 month
Very Dangerous bug in XA connection pooling and SL EJBs with jboss-4.2.3 & latest postgresql-8.4-701.jdbc3.jar
by Achilleas Mantzios
Introduction
========
This bug has the potential effect of xactions which under certain condition should rollback, to behave
as if autocommit is true.
The workaround is to use local-tx-datasource with the standard driver org.postgresql.Driver instead of
xa-datasource with org.postgresql.xa.PGXADataSource.
The description below is with FreeBSD diablo-1.5 , but its exactly the same with SLES 10 SP1 and 1.5.0_15.
configuration
==============
server/default/deploy/postgres-xa-ds.xml
-------------------------------------------------------------------
<datasources>
<xa-datasource>
<jndi-name>pgsql</jndi-name>
<use-java-context>true</use-java-context>
<xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class>
<xa-datasource-property name="ServerName">localhost</xa-datasource-property>
<xa-datasource-property name="PortNumber">5432</xa-datasource-property>
<xa-datasource-property name="DatabaseName">dynacom</xa-datasource-property>
<xa-datasource-property name="User">postgres</xa-datasource-property>
<xa-datasource-property name="Password">xxxxx</xa-datasource-property>
<xa-datasource-property name="Compatible">8.2</xa-datasource-property>
<track-connection-by-tx/>
<min-pool-size>1</min-pool-size>
<max-pool-size>2</max-pool-size>
<metadata>
<type-mapping>PostgreSQL 8.0</type-mapping>
</metadata>
</xa-datasource>
</datasources>
Description
========
Consider the following test case:
This code is executed:
StatusHome sthome = (StatusHome) ic.lookup("java:comp/env/ejb/Status");
Status stat = sthome.create();
"Status" is a SL Session EJB, which is defined to run with @ejb.transaction type = "Required"
Whenever the above is executed, i see in pgsql log:
postgres [23247] 2010-03-02 16:04:09.377 EET line:8 LOG: execute S_1: BEGIN
postgres [23247] 2010-03-02 16:04:09.378 EET line:9 LOG: execute <unnamed>: select ....
postgres [23247] 2010-03-02 16:04:09.380 EET line:11 LOG: execute S_2: COMMIT
which is correct behaviour. Then the following code (lets name it sql_xact) is executed:
sql_xact:
try {
DataSource ds = (javax.sql.DataSource) ic.lookup("java:comp/env/jdbc/DynacomDB");
con = ds.getConnection();
con.setAutoCommit(false);
st = con.prepareStatement("select now();");
rs = st.executeQuery();
rs.close();
st.close();
con.commit();
}
catch (Exception e) {
out.println("<BR>\n");
out.println("Error: " + e.getMessage());
con.rollback();
e.printStackTrace();
}
finally {
if (con != null) con.close();
}
If the above is executed on the same postgresql backend and immediately after the previous (EJB call) block of code, i see in pgsql log:
postgres [23247] 2010-03-02 16:07:24.088 EET line:24 LOG: execute <unnamed>: select now()
which means no begin-commit/rollback block. at this point a xaction supposed to rollback, is semi-commited.
Now, If however, i execute this block of code:
try {
DataSource ds = (javax.sql.DataSource) ic.lookup("java:comp/env/jdbc/DynacomDB");
con = ds.getConnection();
con.setAutoCommit(true);
st = con.prepareStatement("select now();");
rs = st.executeQuery();
rs.close();
st.close();
}
catch (Exception e) {
out.println("<BR>\n");
out.println("Error: " + e.getMessage());
e.printStackTrace();
}
finally {
if (con != null) con.close();
}
and then sql_xact code again, then the connection gets back to normal, pgsql log looking like:
postgres [23247] 2010-03-02 16:11:57.729 EET line:39 LOG: execute S_1: BEGIN
postgres [23247] 2010-03-02 16:11:57.729 EET line:40 LOG: execute <unnamed>: select now()
postgres [23247] 2010-03-02 16:11:57.730 EET line:41 LOG: execute S_2: COMMIT
I dont think that the usage of XA connections are critical for our case, so i can live with local connections (although i guess
i have a lot of garbage data since the above setup was deployed some 2 years ago.... imagine if i were selling open source to some bank)
Any thoughts as to where the problem might reside? The jboss camp or the pgsql-jdbc camp?
--
Achilleas Mantzios
16 years, 1 month
[JBoss Tools] New message: "hql editor porblem with @GenericGenerator"
by Simon Cigoj
User development,
A new message was posted in the thread "hql editor porblem with @GenericGenerator":
http://community.jboss.org/message/529367#529367
Author : Simon Cigoj
Profile : http://community.jboss.org/people/SimonCigoj
Message:
--------------------------------------------------------------
I use generic generator for generating the id-s for my entities defined like this
@Id @Column(name = "ID_PROJECT", unique = true, nullable = false, scale = 0, insertable = false, updatable = false) @GeneratedValue(generator = "seq_id_project",strategy=) @GenericGenerator(name = "seq_id_project", strategy = "org.hibernate.id.enhanced.TableGenerator", parameters = { @Parameter(name = "segment_value", value = "SEQ_ID_PROJECT"), @Parameter(name = "initial_value", value = "1000"), @Parameter(name = "optimizer", value = "pooled"), @Parameter(name = "increment_size", value = "10") })
public long getIdProject() {
return this.idProject;
}
and when I try using the hql editor to test hql I got the folowing error
org.hibernate.MappingException: could not instantiate id generator&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;at org.hibernate.id.IdentifierGeneratorFactory.create(IdentifierGeneratorFactory.java:98)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;at org.hibernate.mapping.SimpleValue.createIdentifierGenerator(SimpleValue.java:152)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;at org.hibernate.impl.SessionFactoryImpl.(ForUpdateFragment.java:36)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;at org.hibernate.dialect.Dialect.applyLocksToSql(Dialect.java:970)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;at org.hibernate.id.enhanced.TableGenerator.configure(TableGenerator.java:194)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;at org.hibernate.id.IdentifierGeneratorFactory.create(IdentifierGeneratorFactory.java:94)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;... 13 more
maybe some configuration problem? The app works nice with this generator, only the hql editor is porblematic.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/529367#529367
16 years, 1 month
[JBoss Microcontainer Development] New message: "ClassLoadingAdmin"
by Adrian Brock
User development,
A new message was posted in the thread "ClassLoadingAdmin":
http://community.jboss.org/message/529360#529360
Author : Adrian Brock
Profile : http://community.jboss.org/people/adrian@jboss.org
Message:
--------------------------------------------------------------
To mirror what is available in OSGi's PackageAdmin class, I've created a ClassLoadingAdmin interfacethat is implemented by both ClassLoading and Domain.
https://svn.jboss.org/repos/jbossas/projects/jboss-cl/trunk/classloading/...
along with some supporting classes.
This required tidying up the way dependencies were stored for Modules for a number of reasons.
1) The cleanup of dependsOnMe() had some problems, there was a TODO in the code about it.
2) When using ShutdownPolicy=GARBAGE_COLLECTION (GC) the dependsOnMe() no longer gets updated on the DependencyInfo
so it needs to be maintained on the Module.
3) We need to keep track of dependencies after undeployment for the GC shutdown policy so we can handle
refreshModules(null) to re-resolve all deployments that have dependencies that are out-of-date.
4) Some of the queries need to be look at specific types of dependencies, e.g. those exporting a package or importing a module.
The major changes in this are;
* the remembering of the "resolvedModule" in the RequirementsDependencyItem and maintaining it
properly, including the dependsOnMe processing.
* holding a set of "lazyShutdownModules" in the Module class that get cleaned up after calls to refreshModules().
There's probably some other stuff that can get added ClassLoadingAdmin? e.g. those importing a package.
For now I've just been guided by what is available in OSGi, although I have generalized some of that api.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/529360#529360
16 years, 1 month