[jira] Updated: (SM-745) Allow usage of other JMS providers than ActiveMQ
[ https://issues.apache.org/activemq/browse/SM-745?page=all ]
Christian Schneider updated SM-745:
---
Attachment: jmsFlowActiveMQandTibco.zip
I have finished the abstract JmsFlow and the implementations for ActiveMQ and
Tibco.
What do you think can this be included in the servicemix sources ?
I guess the Tibco class should not be included in the package. As it introduces
a dependency on tibco packages.
Perhaps it could exist in a separate module. But then it could also be
interesting to remove all dependencies on ActiveMQ from the core and introduce
a module for ActiveMQ jms flows.
// Setup for Tibco
AbstractJMSFlow flow = new JMSFlowTibco();
flow.setJmsURL("tcp://localhost:7222");
flow.setUserName("admin");
flow.setPassword("");
container.setFlow(flow);
// Setup for ActiveMQ
AbstractJMSFlow flow = new JMSFlowActiveMQ();
flow.setJmsURL("tcp://localhost:61616");
container.setFlow(flow);
> Allow usage of other JMS providers than ActiveMQ
>
>
> Key: SM-745
> URL: https://issues.apache.org/activemq/browse/SM-745
> Project: ServiceMix
> Issue Type: Improvement
>Affects Versions: 3.0.1
>Reporter: Christian Schneider
> Attachments: jmsflow.patch, jmsflow.patch, jmsflow2.patch,
> jmsflow3.patch, jmsFlowActiveMQandTibco.zip
>
>
> JMSFlow and JCA flow are too tightly bound to ActiveMQ. Instead of ActiveMQ
> specific classes jms Interfaces should be used where possible.
> I have attached a patch that replaces ActiveMQConnection and
> ActiveMQConnectionFactory by the jms equivalents.
> There is one possible issue with my patch. The getConnectionFactory now
> returns a ConnectionFactory instead of a ActiveMQConnectionFactory. I don´t
> know if any other part of the sources depends on the specific class.
> My patch is of course only the first step. The next could be having a
> specific subclass JMSFlowActiveMQ that does all stuff that is ActiveMQ
> specific.
> I will deliver a second patch for this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SM-811) servicemix-jms does not set SoapAction property for SOAP jms messages
[
https://issues.apache.org/activemq/browse/SM-811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schneider updated SM-811:
---
Attachment: servicemix-jms-sm-811-2.patch
> servicemix-jms does not set SoapAction property for SOAP jms messages
> -
>
> Key: SM-811
> URL: https://issues.apache.org/activemq/browse/SM-811
> Project: ServiceMix
> Issue Type: Bug
> Components: servicemix-jms
>Affects Versions: 3.0, 3.0.1, 3.1
> Environment: Tested with Tibco EMS as jms server and Tibco Business
> works as system providing the service. The error should also occur with
> ActiveMQ.
>Reporter: Christian Schneider
>Priority: Critical
> Attachments: servicemix-jms-sm-811-2.patch,
> servicemix-jms-sm-811.patch, servicemix-jsr181-sm-811.patch
>
>
> When tibco is the client all works well but when tibco implements the service
> it rejects the soap/jms message as it wants the SoapAction jms property to be
> set.
> I have added a dummy SoapAction in StandardProviderProcessor:
> ...
> MessageProducer producer = session.createProducer(destination);
> TextMessage msg = session.createTextMessage();
> NormalizedMessage nm = exchange.getMessage("in");
> fromNMS(nm, msg);
> String soapAction = "default";
> msg.setStringProperty("SoapAction", soapAction);
> ...
> I was able to do a complete request/reply with tibco in this way. Of course
> the "default" SoapAction will only help if my service has only one method.
> From what I see in Tibco the SoapAction should at least contain the method
> name of the service being called.
> The servicemix-jms component should by default set this property to make it
> more compatible with other soap/jms compatible systems.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SM-811) servicemix-jms does not set SoapAction property for SOAP jms messages
[
https://issues.apache.org/activemq/browse/SM-811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_37920
]
Christian Schneider commented on SM-811:
I have attached a new patch.
The core is the method below where I build the Message from the message
exchange.
The Soapaction is now set as: //
Or / if there is now interface_name.
I think using the interface name is better then the endpoint name. What do you
think?
I have also refactored the startup in the processors and were able to kill some
duplicate code. I hope I did not break anything.
The destination is now initialized in the startup code. I think this should not
harm but do not know exactly.
When I think about it ... the method below should return a Message instead of
TextMessage. I read in the soap binding document I linked that jms binding
should use Bytes Messages. So we are more open for the future with just Message.
What do you think about the patch?
---
protected TextMessage createMessageFromExchange(Session session,
MessageExchange exchange) throws Exception {
TextMessage msg = session.createTextMessage();
NormalizedMessage nm = exchange.getMessage("in");
fromNMS(nm, msg);
// Build the SoapAction from //
String soapAction = "";
if (exchange.getOperation()!= null) {
String interFaceName =
exchange.getInterfaceName()== null ? "" :
exchange.getInterfaceName().getNamespaceURI() +
"/" + exchange.getInterfaceName().getLocalPart();
soapAction = interFaceName + "/" +
exchange.getOperation();
}
msg.setStringProperty("SoapAction", soapAction);
msg.setStringProperty("SOAPJMS_soapAction", soapAction);
return msg;
}
> servicemix-jms does not set SoapAction property for SOAP jms messages
> -
>
> Key: SM-811
> URL: https://issues.apache.org/activemq/browse/SM-811
> Project: ServiceMix
> Issue Type: Bug
> Components: servicemix-jms
>Affects Versions: 3.0, 3.0.1, 3.1
> Environment: Tested with Tibco EMS as jms server and Tibco Business
> works as system providing the service. The error should also occur with
> ActiveMQ.
>Reporter: Christian Schneider
>Priority: Critical
> Attachments: servicemix-jms-sm-811-2.patch,
> servicemix-jms-sm-811.patch, servicemix-jsr181-sm-811.patch
>
>
> When tibco is the client all works well but when tibco implements the service
> it rejects the soap/jms message as it wants the SoapAction jms property to be
> set.
> I have added a dummy SoapAction in StandardProviderProcessor:
> ...
> MessageProducer producer = session.createProducer(destination);
> TextMessage msg = session.createTextMessage();
> NormalizedMessage nm = exchange.getMessage("in");
> fromNMS(nm, msg);
> String soapAction = "default";
> msg.setStringProperty("SoapAction", soapAction);
> ...
> I was able to do a complete request/reply with tibco in this way. Of course
> the "default" SoapAction will only help if my service has only one method.
> From what I see in Tibco the SoapAction should at least contain the method
> name of the service being called.
> The servicemix-jms component should by default set this property to make it
> more compatible with other soap/jms compatible systems.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SM-823) Forward authenticated jms user to service
Forward authenticated jms user to service - Key: SM-823 URL: https://issues.apache.org/activemq/browse/SM-823 Project: ServiceMix Issue Type: New Feature Components: servicemix-jms Reporter: Christian Schneider A jms endpoint that offers a soap/jms service should read the authenticated username from the jms message and forward it through the message exchange to the called service. So this service can do further authorisation. To send the username the jms provider has to be configured with a special option. In Tibco you have to add the following line to queues.conf: > sender_name_enforced. This means that tibco should add the authenticated user name in the jms property JMS_TIBCO_SENDER to every message in every queue. In ActiveMq I have found from the documentation that you can use the option populateJMSXUserID. Then ActiveMQ sets the property JMSXUserID. >From these configuations we see that the username can be in different >properties depending on the jms server. So we have to add a configuation >option to tell servicemix how to retrieve the username from the message. The documentation should help with configuring the jms server. Perhaps we can find the necessary settings for other jms servers too like IBM MQ. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SM-738) Invalid jbi.xml when using maven. no description element
Invalid jbi.xml when using maven. no description element - Key: SM-738 URL: https://issues.apache.org/activemq/browse/SM-738 Project: ServiceMix Issue Type: Bug Components: tooling Affects Versions: 3.0 Reporter: Christian Schneider Priority: Minor When I created a service assembly using maven install I got a jbi.xml like this. The xml schema requires to jbi.xml to include a description element in serviceunit identification. In my case it was not present. I think the maven task should at least create an empty element. Best regards Christian http://java.sun.com/xml/ns/jbi"; version="1.0"> myservice-sa A custom project myservice >Here should be a element. myservice-1.0-SNAPSHOT.zip servicemix-jsr181 --- This was my pom.xml --- http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd";> 4.0.0 com.mycompany myservice-sa jbi-service-assembly 1.0-SNAPSHOT A custom project http://www.myorganization.org logicblaze LogicBlaze Repository http://repo.logicblaze.com/maven2-all/ true true logicblaze LogicBlaze Repository http://repo.logicblaze.com/maven2-all/ true true 3.0.1-incubating net.enbw myservice 1.0-SNAPSHOT org.apache.servicemix.tooling jbi-maven-plugin true service-assembly I just tested again with my service unit pom containing a description element. In this case it was included in the jbi.xml and the file was valid. So the issue only seems to occur if you do not have a description element in your service unit pom. Still I would consider this to be a bug as the description element is optional in the su pom. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SM-739) wsdl for pojos exported by jsr181 endpoint is missing complextypes from other namespaces than the service itself
wsdl for pojos exported by jsr181 endpoint is missing complextypes from other
namespaces than the service itself
Key: SM-739
URL: https://issues.apache.org/activemq/browse/SM-739
Project: ServiceMix
Issue Type: Bug
Components: servicemix-jsr181
Affects Versions: 3.0
Reporter: Christian Schneider
Attachments: jsr181wsdlproblem..zip
I am exporting a pojo Service in namespace http://test1 that uses a Class from
namespace http://test2 as a jsr181 endpoint.
The wsdl I get from jconsole for the endpoint does not include the definition
of the Complextype Person from http://test2.
If you put the Person class in the package test1 the wsdl looks fine. The
problem does not happen when using xfire without servicemix.
Thanks to Ken Berthelot for reporting the problem on the mailing list.
http://mail-archives.apache.org/mod_mbox/geronimo-servicemix-users/200611.mbox/browser
---
My xbean.xml
http://xbean.org/schemas/spring/1.0";
xmlns:jsr181="http://servicemix.apache.org/jsr181/1.0";>
.
---
My Classes
package test1;
import test2.Person;
public interface PersonService {
public abstract void testPerson(Person person);
}
package test1;
import test2.Person;
public class PersonServiceImpl implements PersonService {
/* (non-Javadoc)
* @see test1.PersonService#testPerson(test2.Person)
*/
public void testPerson(Person person) {
}
}
package test2;
public class Person {
String name;
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
The wsdl
http://schemas.xmlsoap.org/wsdl/"; xmlns:ns1="http://test2";
xmlns:soap11="http://schemas.xmlsoap.org/soap/envelope/";
xmlns:soap12="http://www.w3.org/2003/05/soap-envelope";
xmlns:soapenc11="http://schemas.xmlsoap.org/soap/encoding/";
xmlns:soapenc12="http://www.w3.org/2003/05/soap-encoding";
xmlns:tns="http://test1"; xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/";
xmlns:xsd="http://www.w3.org/2001/XMLSchema"; targetNamespace="http://test1";>
http://test1";>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SM-739) wsdl for pojos exported by jsr181 endpoint is missing complextypes from other namespaces than the service itself
[
https://issues.apache.org/activemq/browse/SM-739?page=comments#action_37376 ]
Christian Schneider commented on SM-739:
I have debuged the problem and found out where we get our wrong wsdl from.
The problem is inside Jsr181Endpoint.java in method registerService:
http://svn.apache.org/repos/asf/incubator/servicemix/trunk/deployables/serviceengines/servicemix-jsr181/src/main/java/org/apache/servicemix/jsr181/Jsr181Endpoint.java
First the wsdl is generated by xfire:
// If the wsdl has not been provided,
// generate one
if (this.description == null) {
this.description = generateWsdl();
Then later it is overwritten:
// Flatten it
definition = new WSDLFlattener(definition).getDefinition(interfaceName);
description = WSDLFactory.newInstance().newWSDLWriter().getDocument(definition);
The description that is generated by xfire is correct about the complextype.
The decription from the WSDLFactory is wrong.
Does anybody know why the wsdl from xfire can not be used?
> wsdl for pojos exported by jsr181 endpoint is missing complextypes from other
> namespaces than the service itself
>
>
> Key: SM-739
> URL: https://issues.apache.org/activemq/browse/SM-739
> Project: ServiceMix
> Issue Type: Bug
> Components: servicemix-jsr181
>Affects Versions: 3.0
>Reporter: Christian Schneider
> Attachments: jsr181wsdlproblem..zip
>
>
> I am exporting a pojo Service in namespace http://test1 that uses a Class
> from namespace http://test2 as a jsr181 endpoint.
> The wsdl I get from jconsole for the endpoint does not include the definition
> of the Complextype Person from http://test2.
> If you put the Person class in the package test1 the wsdl looks fine. The
> problem does not happen when using xfire without servicemix.
> Thanks to Ken Berthelot for reporting the problem on the mailing list.
> http://mail-archives.apache.org/mod_mbox/geronimo-servicemix-users/200611.mbox/browser
> ---
> My xbean.xml
>
> http://xbean.org/schemas/spring/1.0";
> xmlns:jsr181="http://servicemix.apache.org/jsr181/1.0";>
>
> .
>
> pojoClass="test1.PersonServiceImpl"
> serviceInterface="test1.PersonService"
> style="wrapped">
>
>
> ---
> My Classes
> package test1;
> import test2.Person;
> public interface PersonService {
> public abstract void testPerson(Person person);
> }
> package test1;
> import test2.Person;
> public class PersonServiceImpl implements PersonService {
> /* (non-Javadoc)
>* @see test1.PersonService#testPerson(test2.Person)
>*/
> public void testPerson(Person person) {
>
> }
> }
> package test2;
> public class Person {
> String name;
> public String getName() {
> return name;
> }
> public void setName(String name) {
> this.name = name;
> }
> }
>
> The wsdl
> xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"; xmlns:ns1="http://test2";
> xmlns:soap11="http://schemas.xmlsoap.org/soap/envelope/";
> xmlns:soap12="http://www.w3.org/2003/05/soap-envelope";
> xmlns:soapenc11="http://schemas.xmlsoap.org/soap/encoding/";
> xmlns:soapenc12="http://www.w3.org/2003/05/soap-encoding";
> xmlns:tns="http://test1";
> xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/";
> xmlns:xsd="http://www.w3.org/2001/XMLSchema"; targetNamespace="http://test1";>
>
> elementFormDefault="qualified" targetNamespace="http://test1";>
>
>
>
> type="ns1:Person"/>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>name="testPersonResponse"/>
>
>
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SM-739) wsdl for pojos exported by jsr181 endpoint is missing complextypes from other namespaces than the service itself
[ https://issues.apache.org/activemq/browse/SM-739?page=all ]
Christian Schneider updated SM-739:
---
Attachment: complextypetestpatch.txt
I have written and attached a Testcase for the problem.
> wsdl for pojos exported by jsr181 endpoint is missing complextypes from other
> namespaces than the service itself
>
>
> Key: SM-739
> URL: https://issues.apache.org/activemq/browse/SM-739
> Project: ServiceMix
> Issue Type: Bug
> Components: servicemix-jsr181
>Affects Versions: 3.0
>Reporter: Christian Schneider
> Attachments: complextypetestpatch.txt, jsr181wsdlproblem..zip
>
>
> I am exporting a pojo Service in namespace http://test1 that uses a Class
> from namespace http://test2 as a jsr181 endpoint.
> The wsdl I get from jconsole for the endpoint does not include the definition
> of the Complextype Person from http://test2.
> If you put the Person class in the package test1 the wsdl looks fine. The
> problem does not happen when using xfire without servicemix.
> Thanks to Ken Berthelot for reporting the problem on the mailing list.
> http://mail-archives.apache.org/mod_mbox/geronimo-servicemix-users/200611.mbox/browser
> ---
> My xbean.xml
>
> http://xbean.org/schemas/spring/1.0";
> xmlns:jsr181="http://servicemix.apache.org/jsr181/1.0";>
>
> .
>
> pojoClass="test1.PersonServiceImpl"
> serviceInterface="test1.PersonService"
> style="wrapped">
>
>
> ---
> My Classes
> package test1;
> import test2.Person;
> public interface PersonService {
> public abstract void testPerson(Person person);
> }
> package test1;
> import test2.Person;
> public class PersonServiceImpl implements PersonService {
> /* (non-Javadoc)
>* @see test1.PersonService#testPerson(test2.Person)
>*/
> public void testPerson(Person person) {
>
> }
> }
> package test2;
> public class Person {
> String name;
> public String getName() {
> return name;
> }
> public void setName(String name) {
> this.name = name;
> }
> }
>
> The wsdl
> xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"; xmlns:ns1="http://test2";
> xmlns:soap11="http://schemas.xmlsoap.org/soap/envelope/";
> xmlns:soap12="http://www.w3.org/2003/05/soap-envelope";
> xmlns:soapenc11="http://schemas.xmlsoap.org/soap/encoding/";
> xmlns:soapenc12="http://www.w3.org/2003/05/soap-encoding";
> xmlns:tns="http://test1";
> xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/";
> xmlns:xsd="http://www.w3.org/2001/XMLSchema"; targetNamespace="http://test1";>
>
> elementFormDefault="qualified" targetNamespace="http://test1";>
>
>
>
> type="ns1:Person"/>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>name="testPersonResponse"/>
>
>
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SM-745) Allow usage of other JMS providers than ActiveMQ
[ https://issues.apache.org/activemq/browse/SM-745?page=comments#action_37492 ] Christian Schneider commented on SM-745: I have found a feature in tibco ems that is similar to activemq´s advisory topics. They call it montor topics. So it should be possible to write a special JMSFlow for Tibco ems. I think I will do so later this winter. I also think jms and jca flows could share a common base class. The handling of endpoint publishing is quite similar. > Allow usage of other JMS providers than ActiveMQ > > > Key: SM-745 > URL: https://issues.apache.org/activemq/browse/SM-745 > Project: ServiceMix > Issue Type: Improvement >Affects Versions: 3.0.1 >Reporter: Christian Schneider > Fix For: 3.1 > > Attachments: jmsflow.patch, jmsflow.patch, jmsflow2.patch, > jmsflow3.patch > > > JMSFlow and JCA flow are too tightly bound to ActiveMQ. Instead of ActiveMQ > specific classes jms Interfaces should be used where possible. > I have attached a patch that replaces ActiveMQConnection and > ActiveMQConnectionFactory by the jms equivalents. > There is one possible issue with my patch. The getConnectionFactory now > returns a ConnectionFactory instead of a ActiveMQConnectionFactory. I don´t > know if any other part of the sources depends on the specific class. > My patch is of course only the first step. The next could be having a > specific subclass JMSFlowActiveMQ that does all stuff that is ActiveMQ > specific. > I will deliver a second patch for this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (GERONIMO-4576) Make persistence exceptions more visible to client
[ https://issues.apache.org/jira/browse/GERONIMO-4576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated GERONIMO-4576: -- Attachment: GERONIMO-4576-1.patch I attached a patch that fixes this issue. The problem was that calling setRollbackOnly() created a quite uninformative exception and set it using markRollbackCause(e). Then at a later point the real exception could not be set anymore as markRollbackCause only sets the exception if the current one is not set. My patch avoids the generic exception and only calls markRollbackCause if a real exception was given. > Make persistence exceptions more visible to client > -- > > Key: GERONIMO-4576 > URL: https://issues.apache.org/jira/browse/GERONIMO-4576 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: persistence >Affects Versions: 2.2 > Environment: Linux, Windows >Reporter: Joe Bohn >Priority: Minor > Fix For: Wish List > > Attachments: GERONIMO-4576-1.patch > > > See http://issues.apache.org/jira/browse/GERONIMO-3907 for details of the > original problem. That core problem was resolved. However, upon resolution > it was mentioned that it would be beneficial to report more specific failure > information back to the client. From GERONIMO-3907: > Ralf Baumhof - 06/May/08 06:17 AM > Today if have tested the new Geronimo release 2.1.1 (published on > 28.04.2008). The problem is now fixed. If the server gets an error on trying > a commit, this error is now thrown to the web bean. > Exception text: > javax.ejb.EJBTransactionRolledbackException: Transaction was rolled back, > presumably because setRollbackOnly was called during a synchronization: > Unable to commit: transaction marked for rollback Root Cause: > javax.transaction.TransactionRolledbackException : Transaction was rolled > back, presumably because setRollbackOnly was called during a synchronization: > Unable to commit: transaction marked for rollback > Unfortunately there is no proper root cause attached to the exception. So the > cause can only be seen in the server console, but can not be reported to the > user. It would be very nice if you could change this in a later release. > Thanks for your help. > Vincent MATHON - 06/Nov/08 02:03 AM > I agree that exceptions on the server side should not be thrown to the client > side since such exceptions types might not be known by the client. However, > for unit testing purpose, it is useful to attach the root cause to the > RollBackException. I have modified a few lines in > org.apache.geronimo.transaction.manager.TransactionImpl.java to attach the > root cause in case of RollBackException and it works for my unit testing > purpose (I have not enough background on the java transaction architecture > topic to submit a patch for production). It would be great to define a > configuration parameter that permits to provide the root cause to the client > and keep the current behaviour that does not by default. > Geoff Callender - 22/Dec/08 03:36 AM > It's useful for more than unit testing - it's essential to be able to inform > the client what's wrong with the request. I've added some examples of this to > https://issues.apache.org/jira/browse/OPENEJB-782 . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (GERONIMO-6564) Move the JSONB api from Johnzon to Geronimo
[ https://issues.apache.org/jira/browse/GERONIMO-6564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider updated GERONIMO-6564: -- Attachment: GERONIMO-6564-1.patch The import versions are wrong. You need to leave out the version in the maven bundle plugin config. After the patch it takes the import ranges from the exported packages it sees in the maven dependencies. So it then correctly uses the 1.0 version for jsonb and the 1.1 version for jsonp. > Move the JSONB api from Johnzon to Geronimo > --- > > Key: GERONIMO-6564 > URL: https://issues.apache.org/jira/browse/GERONIMO-6564 > Project: Geronimo > Issue Type: Task > Security Level: public(Regular issues) > Components: specs >Reporter: Mark Struberg >Assignee: Mark Struberg > Attachments: GERONIMO-6564-1.patch > > > The JSONB api (JSR-367) got finished in Apache Johnzon and is ready to get > moved to geronimo and get released. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
