New binding component: SMPP

• Key: SM-1623
• Type: Improvement
• Status: Resolved
• Resolution: Fixed
• Priority: Major
• Assignee: Jean-Baptiste Onofré
• Reporter: Rohit Joshi
• Component/s: servicemix-components
• Fix Version/s: 4.0, 3.3

Description

I am submitting here source code for SMPP binding component. See the attached tar file.
Attached servicemix-component.tar file contains following files. It should be deployed under apache-servicemix-3.2.2/src/common directory.

********
SOURCE
***********
servicemix-components/src/main/java/org/apache/servicemix/components/smpp/
servicemix-components/src/main/java/org/apache/servicemix/components/smpp/SMPPMarshaler.java
servicemix-components/src/main/java/org/apache/servicemix/components/smpp/SMPPPoller.java
servicemix-components/src/main/java/org/apache/servicemix/components/smpp/SMPPSender.java
servicemix-components/src/main/java/org/apache/servicemix/components/smpp/servicemix.xml
******
TEST
********
servicemix-components/src/test/java/org/apache/servicemix/components/smpp/
servicemix-components/src/test/java/org/apache/servicemix/components/smpp/SMPPPollTest.java
servicemix-components/src/test/java/org/apache/servicemix/components/smpp/SMPPTest.java
*********
pom.xml
********
servicemix-components/pom.xml
this file adds the dependency on smppapi.

<dependency>
<groupId>smppapi</groupId>
<artifactId>smppapi</artifactId>
<version>0.3.7</version>
<optional>false</optional>
</dependency>

Comments

[Lars Heinemann]

Rohit,

I am sorry, but we cannot integrate your component into smx unless you grant ASF the license. (you forgot to switch the radio button for your attachment).

Regards
Lars

[Rohit Joshi]

Attached servicemix-smpp.tar is new SMPP binding component which should be copied under src/deployables/bindingcomponent directory. It will create servicemix-smpp component which has two endpoints.

1. SMPPSenderEndpoint : Sending SMS using SMPP protocol
2. SMPPPollerEndpoint : Receiving SMS using SMPP protocol

For more information, see the package.html under servicemix-smpp/src/main/java/org/apache/servicemix/smpp directory.

apacheservicemix/src/deployables/bindingcomponent/pom.xml must be modified to include servicemix-smpp as a module to be included.

[Rohit Joshi]

Attached servicemix-components.tar file includes SMPP binding component related source code which should go into apacheservicemix/src/common directory. It includes SMPPPoller and SMPPSender endpoints.

Please find attached here smpp_sample which should go into src/samples directory. It includes SMPP Service Unit and SMPP Service Assembly.

[Lars Heinemann]

This contribution can't be integrated into ServiceMix directly due to licensing issues. The used dependency "smppapi" is licensed under the LGPL license. (see: http://www.apache.org/legal/3party.html)

I created a separate project for hosting such components.
You can find it under:
http://code.google.com/p/servicemix-extras/

I already reworked most of your contribution to make the component fully JBI compliant.
There is also a 1.0-SNAPSHOT version available for you to test if it works.

You can download the component here:
http://code.google.com/p/servicemix-extras/source/browse/m2-repo/com/google/code/servicemix-extras/components/servicemix-smpp/1.0-SNAPSHOT/servicemix-smpp-1.0-20081010.081203-1-installer.zip

Just drop it to the hotdeploy folder.
I will setup a wiki page for using this component as well but this will take some time. Until then please refer to the source code for how to configure endpoints.

[Rohit Joshi]

Hi Lars,
If it is not going to Apache, please remove these code from google code.
I don't want to contribute.

Thx.
Rohit Joshi

–
This e-mail and any attachment is for authorized use by the intended
recipient(s) only. It may contain proprietary material, confidential
information and/or be subject to legal privilege. It should not be copied,
disclosed to, retained or used by, any other party. If you are not an
intended recipient then please promptly delete this e-mail and any
attachment and all copies and inform the sender. Thank you.

[Guillaume Nodet]

Hi Rohit !

We would love to include it at apache, but due to the ASF licensing policy (see http://www.apache.org/legal/3party.html) we can't release anything with a LGPL dependency jar included.
If you really want to code to be at Apache, we can find ways around the problem.
A first solution would be to use an ASL wrapper library that could be used as a bridge between the LGPL jar api and the component. We could include the bridging library in the component, and the user would be able to use the component by downloading the LGPL jar himself and putting it in the lib folder of ServiceMix.
Another solution would be to include the code at apache in a branch / sandbox and never release it (I would have to check if this is really possible with the legal guys).

Also, note that Lars did a pretty big refactoring of the code you contributed to make it a standard JBI component instead of a lightweight component.

That said, if you really don't want to contribute it in some form or another, we'll remove it from the google code project.

[Rohit Joshi]

Guillaume,
thanks for your quick response. I would love to contribute to apache as
we have been using apache web server. So if we can include in apache, that
would be good.

I have submitted three attachment which includes lightweight component,
JBI standard component and SU/SA for testing.

Try if we can including in apache.

Thx.
Rohit Joshi

–
This e-mail and any attachment is for authorized use by the intended
recipient(s) only. It may contain proprietary material, confidential
information and/or be subject to legal privilege. It should not be copied,
disclosed to, retained or used by, any other party. If you are not an
intended recipient then please promptly delete this e-mail and any
attachment and all copies and inform the sender. Thank you.

[Christian Mueller]

I'm very interested in a smpp component for servicemix. What's the status?
I can't download the attachements. They are in the svn repo?

Thx,
Christian

[Rohit Joshi]

I submited smpp component but it was not accepted due to itvhad smpp
library with lgpl license.

Sent from my iPhone

On Jan 8, 2009, at 12:24 PM, "Christian Mueller (JIRA)"

[Lars Heinemann]

This component has been reworked from the contribution of Rohit. Due to some license problem with the smppapi library which is under LGPL license and not compatible with our licensing we were not able to integrate it directly into ServiceMix.

Because of that I initially moved the component to the Google Code project mentioned above. You can also download a first version there for testing purpose but be warned that I never tested it after the rework.

We want to move this component back into the ServiceMix repo as soon as it gets a replacement for the smppapi library. I had a first look at the jsmpp library also hosted at Google Code if it is fullfilling our needs but currently I haven't got the time to finish my work.

If someone wants to volunteer for this work please have a look at:
http://svn.apache.org/viewvc/servicemix/sandbox/lhein/servicemix-smpp/

This is the current state of the component with the new jsmpp library. It is currently not working and may even not compile (don't know exactly because I haven't worked at it for several weeks).

Feel free to provide patches if you got it working.

Regards
Lars

[Jean-Baptiste Onofré]

I make a look on it and keep you informed about the progress.

[Rohit Joshi]

I looked at the source code in the snapshot code. It still uses opensmpp
library calls and that's the reason it doesn't work. I will try to work on
it this weekend if time permits.
Due to the poor performance of Apahce Ode in ServiceMix , we had to choose
Glassfish/OpenESB solution so I stopped working on this binding component
and had to write one for OpenESB.

On Fri, Jan 9, 2009 at 3:16 PM, Jean-Baptiste Onofré (JIRA) <[e-mail]

–
This e-mail and any attachment is for authorized use by the intended
recipient(s) only. It may contain proprietary material, confidential
information and/or be subject to legal privilege. It should not be copied,
disclosed to, retained or used by, any other party. If you are not an
intended recipient then please promptly delete this e-mail and any
attachment and all copies and inform the sender. Thank you.

[Jean-Baptiste Onofré]

To be compatible with Apache 2.0 license, I will commit a SMPP component that use jsmpp :
http://code.google.com/p/jsmpp/

I hope to be able to send the component source code tomorrow (sunday) evening.

Lars, are you OK if the bug is assigned to me ?

[Lars Heinemann]

Of course, JB.

As I already told you, the code is not compilable atm. because I just switched the lib to jsmpp and then started looking at what to change.
So there is still a lot to do.

Regards
Lars

[Christian Mueller]

Thanks for the quick answers.
I still waiting for the new version and will test it, if you finish your work. Let me know, if you need any assistance...

Regards,
Christian

[Jean-Baptiste Onofré]

Ropen the issue to implement the component using jsmpp (Apache 2.0 compatible).

[Jean-Baptiste Onofré]

I have begin to implement the component using jSMPP. I need more time to work on it but you can see the current source code here :
http://svn.nanthrax.net/servicemix-smpp/trunk/

I will make a new commit this evening (french time).

[Jean-Baptiste Onofré]

The core component is complete but I need to validate it with JUnit (especially around the TON and NPI).

[Christian Mueller]

Hello Jean-Baptiste,

I'm happy with the progress of this smpp binding component and I have played
with it (get from your svn repo). Thank you for your work.

I will give you some feedback for further improvements:

• With your last commit (revision 17) you add the dependency to 'sl4j'
  instead of 'slf4j' (missing 'f') :o)
• see pom.xml.patch

• For an easy test, I want to read the sms message with a file poller and
  send it to the smpp sender. Because the file poller supports only In-Only
  MEPs, and I think it's a good idee that the smpp component also supports the
  In-Onyl (and Robust-In-Only) MEP, I have added the 'processInOnly' method.
• In the 'processInOut' method, the checks of ExchangeStatus.DONE,
  ExchangeStatus.ERROR and exchange.getFault() are not necessary, because the
  super class ProviderEndpoint ensures this (this is my understanding).
• see SmppSenderEndpoint.java.patch

• For a more advanced test, I have intermediary a eip pipeline to bridge
  from the file pollers In-Only MEP to the smpp senders In-Out MEP and send
  the response to a file sender. In this scenario, I got an Exception. I don'
  why, but I will looking for that at the evening...

I hope my feedback is welcome and helpfully...

Regards,
Christian

[Jean-Baptiste Onofré]

Hi Christian,

thanks a lot for your feedback.

Concerning the sl4j dependency, yes, it's a mistake. I will correct this evening. For now, the jsmpp is on my maven repository (I will add the sl4j this evening).

Concerning the MEP, I have add only In-Out only on the component. But I'm agree with you that In-Only is used most of the time. I will add a both MEP property on the endpoints and support new endpoints required methods.

I have add a set of unit tests : marshaler transformation, component itself, xbean deployment, etc. I haven't completed yet all tests that's why it's not in unstable .

I will keep you posted soon about the JUnit test results.

Regarding your feedback, I will add new JUnit tests to reproduce your use cases.

Thanks a lot for your tests !!

[Christian Mueller]

Hi Jean-Baptiste,

I'm not sure, whether a MEP property is necessary in the
'SmppSenderEndpoint'. 'SmppSenderEndpoint' can support In-Only,
Robust-In-Only and In-Out, depending on the request MEP.
'SmppPoolerEndpoint' should have a MEP property and support the In-Only and
Robust-In-Only MEPs.

I fixed the problem I had with the In-Out MEP:

• The call 'this.getChannel().send(exchange);' in the 'processInOut' method
  of the 'SmppSenderEndpoint' is not necessary, bacause the super class
  'ProviderEndpoint' call this method for us, after calling 'processInOut'.
• Because we reading the source of the normalized in message multiple times,
  we need to call 'MessageUtil.enableContentRereadability(in);' before we read
  the source the first time. Else, we receive a
  'javax.xml.transform.TransformerException: java.io.IOException: Stream
  closed'.
• The call to 'MessageUtil.transferInToOut(exchange, exchange);' throws an
  'MessagingException', because the normalized out message is not null (see
  line 360 of 'org.apache.servicemix.jbi.messaging.MessageExchangeImpl'). I
  (and also my manually tests) thinking that 'MessageUtil.transfer(in, out);'
  does the right.
• see SmppSenderEndpoint.java.patch (patch to revision 17)

Regards,
Christian

[Jean-Baptiste Onofré]

Thanks again Christian for this patch set.
I merge on my SVN repository and resume unit tests.

I have deployed slf4j on my maven repository too.

Commit changes right now.

[Lars Heinemann]

I added the current state to smx repository after fixing some of the classes.
In future it would be nice to have patches for that version so updating the component is easier for committers.

Regards
Lars

[Christian Mueller]

Hi Jean-Baptiste,

thanks, I got the svn repo updates (revision 20).
Today, I worked on the 'SmppPollerEndpoint':

• I think 'SmppConsumerEndpoint' is the better name, bacause this component
  is subclassed from 'ConsumerEndpoint' and not from 'PollingEndpoint' and
  follows the smx naming schema (e.G. 'JmsConsumerEndpoint',
  'HttpConsumerEndpoint', ...).
• now, you configure the consumer endpoint with '<smpp:consumer ...>'
  instead of '<smpp:poller ...>'
• The check in the validate method, whether the 'getMarshaller()' call
  returns an instance of 'SmppMarshaller' is not necessary, because
  'getMarshaller()' returns an 'SmppMarshaller'.
• Modify the 'process()' method (now, acts like the 'QuartzEndpoint')
• Added the defaultMep property and getter/setter with the default to
  'In-Only' (analog to HttpConsumerEndpoint)
• Modify the 'connect()' method to create the MessageExchange for the
  configured MEP (In-Only or Robust-In-Only), configure the exchange and send
  it.
• see smpp_consumer_endpoint.patch

I hope you agree with my changes...

Regards,
Christian

[Jean-Baptiste Onofré]

Hi Christian,

In response to your comment :

• I'm agree to rename SmppPollerEndpoint to SmppConsumerEndpoint. I make the change now.
• I change the xbean element too
• As you can define your own marshaler (you have a marshaler property), I check if the marshaler provided by the user is a SmppMarshaler (instanceof). That's why you have this check in the validate() method. If the user hasn't define its own marshaler, I set a default one, else I check if the one provided is a SmppMarshaler.
• I check and merge your changes as I have already added the defaultMep property

Thanks

Regards
JB

[Jean-Baptiste Onofré]

As Lars has commited the SMPP component on the ASF SVN repo, now I will submit patches (not yet use my svn repo).

@Lars : concerning the jsmpp maven repo, do you think that we can store on the ASF one ?

[Lars Heinemann]

• I think 'SmppConsumerEndpoint' is the better name, bacause this component
  is subclassed from 'ConsumerEndpoint' and not from 'PollingEndpoint' and
  follows the smx naming schema (e.G. 'JmsConsumerEndpoint',
  'HttpConsumerEndpoint', ...).

--> There are other components using Poller and Sender...so no need to change it imho.

• now, you configure the consumer endpoint with '<smpp:consumer ...>'
  instead of '<smpp:poller ...>'

--> see above

• The check in the validate method, whether the 'getMarshaller()' call
  returns an instance of 'SmppMarshaller' is not necessary, because
  'getMarshaller()' returns an 'SmppMarshaller'.

--> well. You are right here but if someone tries to put a class in here which is not
implementing the SmppMarshalerSupport interface it will just throw a ClassCastException.
We can safely remove this check. (Nanthrax, could you do that?)

• Modify the 'process()' method (now, acts like the 'QuartzEndpoint')

--> well...the naming is not really the best because it makes you think it overrides the process method from
the super class.

• Added the defaultMep property and getter/setter with the default to
  'In-Only' (analog to HttpConsumerEndpoint)

--> that sounds interesting. But as a first step the InOnly would be enough. Just imagine what happens when
using a InOut exchange. What do you do with the result from the NMR? Then you need to implement sending
logic inside the poller endpoint. I would leave that away for the moment.

• Modify the 'connect()' method to create the MessageExchange for the
  configured MEP (In-Only or Robust-In-Only), configure the exchange and send
  it.

--> see above

Thanks for the input Christian. Please refer to the official version in the ASF repo in future because it makes it easier to
apply patches.

Regards
Lars

[Lars Heinemann]

After some rethinking it would be maybe better to use the naming strategy Christian suggested.

[Christian Mueller]

Hello Lars, hello Jean-Baptiste,

sure, in future my patches will refer to the official version in the ASF
repo.

Regards,
Christian

[Christian Mueller]

Hi Lars, hi Jean-Baptiste,

Today, I fixed the 'SpringComponentTest'

• modify the 'validate()' method and create the 'DefaultSmppMarshaler', if
  no marshaler set (like HttpProviderEndpoint), because the test throws a
  NullPointerException.
• modify the spring.xml file and change the definition from 'smpp:sender' to
  'smpp:provider', because the XBean definition has changed (for a while).
• see SpringComponentTest.patch

Regards,
Christian

[Christian Mueller]

I also fixed the SmppXBeanDeployerTest:

• modify the xbean.xml file and change the definition from 'smpp:sender' to
  'smpp:provider', because the XBean definition has changed (for a while).
• see SmppXBeanDeployerTest.patch

Regards,
Christian

[Christian Mueller]

Hi Lars, hi Jean-Baptiste,

what should be the next steps? I have the following on my TODO list:

• create unit test for SmppConsumerEndpoint
• create unit test for SmppProviderEndpoint
• SmppConsumerEndpoint should have defaultMep attribute which defines the
  message exchange pattern to use by this component (In-Only and
  Robust-In-Only)
• DefaultSmppMarshaler should read (write?) the element
  'RegisteredDelivery'. So, we can request a delivery receipt from the smsc.
• DefaultSmppMarshaler should read (write?) the element
  'ScheduleDeliveryTime'. So, we can define when the message should be
  deliverd.
• DefaultSmppMarshaler should read (write?) the element 'ValidityPeriod'.
  So, we can define the validity period of the message.

Regards,
Christian

[Christian Mueller]

And one change more:

• renamed the test 'SmppMarshalerTest' to 'DefaultSmppMarshalerTest' and
  moved this test from package 'org.apache.servicemix.smpp' in the package
  'org.apache.servicemix.smpp.marshaler'.
• see DefaultSmppMarshalerTest.patch

Regards,
Christian

[Lars Heinemann]

Christian,

I would think your TODO is fine but you should talk with Jean about that because he has the issue assigned.
For the component:
If all test errors are corrected and the build works fine, then leave me a note so I can move the component into our build cycle.

Regards
Lars

[Christian Mueller]

Hi Lars,

with the patches, I provided yesterday, all unit tests pass.

Christian

[Lars Heinemann]

Christian,

I have applied the 3 patches from yesterday...same result...test results in 2 failures.
Do you have some special testing environment? Remember, we have no infrastructure for receiving / sending SMS at ASF. So if
you want to test sending / receiving you need to emulate this for example via Mock.

I updated the asf sources of the component. feel free to check out and re-test.

[Jean-Baptiste Onofré]

Sorry guys, I'm with a customer today. I will update and test this evening.

Regards
JB

[Jean-Baptiste Onofré]

Christian, concerning the TODO list, I'm quite agree (and some are already planned).

[Christian Mueller]

Hi Lars hi Jean-Baptiste,

Thanks. Yes, the 'SmppXBeanDeployerTest' and 'SpringComponentTest' tests are
integration tests. They need a running Short Message Service Center. Should
we move this tests to 'src/it/java' or anywhere else? Maybe, maven plans to
support the 'integration-test phase in future (
http://docs.codehaus.org/display/MAVENUSER/Maven+and+Integration+Testing).

Also, I'm agree with you, we should provide 'real' unit tests with a mock
implementation.

Jean-Baptiste, on which todo's you plan concrete to work? Because the
overlap...

I would like to start with the unit tests for SmppConsumerEndpoint and
SmppProviderEndpoint.

Do you have a prefered mock library? I'm familiar with
easymock/easymock-classextension...

And one more feature would be useful for our clients. Specify the duration,
a enquire link request will be send to the SMSC. At the moment, every 5
seconds a request is send. In our production env, we need a enquire link
only at 4 minutes...
You agree with this offer, to add a enquireLinkPeriod attribute to the
consumer/provider?

Christian

[Lars Heinemann]

Christian:

EasyMock is fine imho.
The duration stuff looks useful to me as well.

Regards
Lars

[Jean-Baptiste Onofré]

Christian,
I prefer to let the test in the standard location : src/test/java.

Nevertheless, we need :
1/ better catch of exceptions on the jsmpp level
2/ add a SMSC simulator in unit test like http://www.seleniumsoftware.com/downloads.html

Concerning the mock library, easymock is fine for me.

No problem to add an attribute enquireLinkPeriod, it's a good idea.

Concerning the roadmap, we need to deal together around who make what

Currently, I have begun consumer and provider endpoint with usage of Selenium SMSC simulator. I can work on enquireLinkPeriod attribute add tomorrow afternoon (french time).

[Jean-Baptiste Onofré]

I have added enquireLinkTimer and transactionTimer on both consumer and provider endpoints.

[Jean-Baptiste Onofré]

After discussing with Lars and Guillaume, it's better to use mock. I'm begin to use easymock in endpoint tests.

[Christian Mueller]

Hi Lars, hi Jean-Baptiste,

I worked yesterday on simple unit tests for SmppProviderEndpoint and
SmppConsumerEndpoint and found the following failures:

• NPE in SmppConsumerEndpoint if no marshaler is explicit provided
• validation of the availability of the password in SmppProviderEndpoint,
  because the password is optional

At the moment, I can't submit a patch because I have the uncommited changes
from Jean-Baptists last patch in my workspace... If the patch is commited, I
will submit the patch.

Jean-Baptiste, just to clarify: You will implement the unit tests for
SmppProviderEndpoint and SmppConsumerEndpoint which starts automaticly (in
setUp() method) the SMPPSim or something else?

Christian

[Jean-Baptiste Onofré]

Hi Christian,

After dealing with Lars and Guillaume, I won't use SMPPSim because :

• the SMPPSim license is GPL2 and so it's compatible with the Apache license
• the SMX tests should be based mainly on mocks.

That's why, I'm going to use easymock as SMSC simulator. For now, I'm investigating how to create (especially on which level) the mock :

• a SMPPSession mock
• a whole SMSC mock
• etc

If you have any proposal in your mind, I'm interested

Regards
JB

[Christian Mueller]

Hi Jean-Baptiste, hi Lars,

I finished my work for the following features:

• DefaultSmppMarshaler should read and write the element
  'registeredDelivery'. So, we can request a delivery receipt from the smsc.
• DefaultSmppMarshaler should read and write the element
  'scheduleDeliveryTime'. So, we can define when the message should be
  deliverd.
• DefaultSmppMarshaler should read and write the element 'validityPeriod'.
  So, we can define the validity period of the message.

I also enlarged and modified the 'DefaultSmppMarshalerTest' (see
'DefaultSmppMarshaler.java.patch')

Christian

[Jean-Baptiste Onofré]

Thanks Christian for your patch. I will apply on my local svn copy and make a quick review. I will keep you posted.
On my side, I have advanced on a SmppServerMock to be able whole component testing.
We need to wait for Lars concerning applying the patch on the main SMX svn repo (I haven't the permission to do it now).

Regards
JB

[Lars Heinemann]

Sorry Christian,

you have to grant the permissions to your contribution (patch) to the ASF.
So if you want to get the patches applied, please re-upload the patches and this time
set the checkbox for granting license to asf.

Regards
Lars

[Christian Mueller]

Hi Lars,

sorry for the circumstances, I send the patch per e-Mail...
Now, I upload the file again and grant the ASF license.

Regards,
Christian

[Christian Mueller]

Hi Jean-Baptiste,

sounds good... Do you mean, you start this SmppServerMock in the tests setUp
method and this mock listen on a tcp port and will return a default/mock
response for a given request?

One thing I notices for two days. SmppConsumerEndpoint and
SmppProviderEndpoint have the same attributes and the same validate method.
Should they have the same super class? Maybe AbstractSmppEndpoint...

If Lars accept and commited your patch, I will apply the patch I announced
two days ago (fixed the NPE in SmppConsumerEndpoint if no marshaler is
explicit provided; wrong validation of the availability of the password in
SmppProviderEndpoint, because the password is optional)

In my next free time, I will looking for a better catch of exceptions on the
jsmpp level, you wrote few days ago...

Christian

[Jean-Baptiste Onofré]

Hi Christian,

Yes, you have right, the SMPP server mock is ServerSocket adapter which listen on a given port and receiving SMPP streams. I will add a sending method to simulate a SMS incoming.

Concerning the attribute, you have right, we can create an abstract super class. As soon as Lars will commit the patches set, I will create a new one with the super class. I will discuss with Guillaume if I can have writer permission on some part of the ASF svn repo.

Concerning exception catching, I have begun some changes around this. I will apply after patches commit.

I have created a first wiki page around the SMPP component :
http://servicemix.apache.org/servicemix-smpp.html

I will updated this wiki page with component changes.

Regards
JB

[Christian Mueller]

Hi Jean-Baptiste,

the wiki page looks nice.

To avoid the overlap, what do you think, I can work on? On my todo list, I
notice the following thinks:

• SmppProviderEndpoint should support the In-Only mep
• SmppProviderEndpoint should support the Robust-In-Only mep

• SmppConsumerEndpoint should support the Robust-In-Only mep
• SmppConsumerEndpoint should support the In-Out mep (for receiving SMS from
  the SMSC)

Christian

[Lars Heinemann]

I removed the patches without granting of the rights to the ASF.
The other patch will be applied soon.

[Lars Heinemann]

Applied both patches.

Please check if everything is as you wanted it. There are still 2 tests failing.

Regards
Lars

[Jean-Baptiste Onofré]

Thanks Lars for the commit. It looks fine for me.

The two test failures are due to the absence of SMPP server. To solve it, we need :

• to better jSMPP exception catching
• SMPP server mock

I keep you posted.

[Christian Mueller]

Hi Jean-Baptiste, hi Lars,

I provide two patches for the SmppComponents. The SmppConsumerEndpoint.java.patch fixed the NPE in SmppConsumerEndpoint, if no marshaler is explicit provided. The SmppProviderEndpoint.java.patch correct the validation of the availability of the password in
SmppProviderEndpoint, because the password is optional and not required (SMPP specification chapter 4.1.1 and 5.2.2).

Christian

[Jean-Baptiste Onofré]

Thanks Christian.

I'm going to apply the patch on my working copy and make a review on it. Keep you posted.

JB

[Jean-Baptiste Onofré]

Christian, I have validated your patch. I will have the permission to commit on the SMX svn repository soon. I will commit as soon as my account is activated.

JB

[Christian Mueller]

Hi Jean-Baptiste,

sounds good...
The next patch is waiting...

Regards,
Christian

On Thu, Feb 5, 2009 at 8:22 AM, Jean-Baptiste Onofré (JIRA) <[e-mail]

[Christian Mueller]

Hi Jean-Baptiste,

any progress?

Regards,
Christian

[Jean-Baptiste Onofré]

Hi Christian,

sorry for the delay, but I'm stuck with a customer this week. I will commit and make whole component review this week end.

Now I have the permission to commit on the ASF svn repo so I can commit your patch.

My apologize again for the delay.

Regards
JB

[Christian Mueller]

Hi Jean-Baptiste!

No problem...
Next week, I'm on vacation in Austria... :o)

Regards,
Christian

[Jean-Baptiste Onofré]

I have included Christian's patches on endpoints, changed unit test to avoid failure as I don't have commited SMPP server mock yet.
Commit done.

[Jean-Baptiste Onofré]

After dealing with Lars, I will include the servicemix-smpp component to the build cycle.

[Christian Mueller]

Hi Jean-Baptiste!

It looks like you are busy. If it's ok for you, I will provide my patch which enables SmppProviderEndpoint and SmppConsumerEndpoint to deal with In-Only and Robust-In-Only MEPs. (If in SmppProviderEndpoint#process() an exception is thrown, we forward the exception to the service client. If MessageReceiverListener#onAcceptDeliverSm() throws an exection, we throw a org.jsmpp.extra.ProcessRequestException for the SMSC).

It's ok for you?

Regards,
Christian

[Jean-Baptiste Onofré]

Hi Christian,

I was busy this week. I'm back in the business now.

I'm ok with your patches proposal. Feel free to attach in this Jira.

During this time, I resume my SMPP mock and add the SMPP BC in the SMX distribution.

Thanks
Regards
JB

[Jean-Baptiste Onofré]

servicemix-smpp 2009.01 has been included in SMX4.

I make the change the include in next SMX3 release.

[Jean-Baptiste Onofré]

servicemix-smpp 2009.01 component has been included in the SMX3 trunk.

I close this task as a first version of the component has been deployed.

New features, enhancements or bugs on this component will raise jira tasks.