? I’m excited to announce that Early Access is now available for our new PubSub+ Messaging API for Java!
Java as a language, and how developers use it, has evolved quite a bit over the past 15 years; and while JCSMP (our current Java API) has treated us well it is our oldest API and it is definitely time for a new, modern and clean API for all of the Java developers out there. Yes, this means no more usage of XMLMessage objects when you’re not even using XML This new Java API is intended to modernize the way developers write Java clients for PubSub+ Event Brokers and will take a builder style approach – similar what our recently released Python API does.
Enough jibber jabber, here is the info you need to try it out:
This Early Access API currently supports:
Connection management to PubSub+ event brokers
Addition and removal of topic subscriptions
Sending and receiving Direct and Guaranteed Messages
Message compression
Use of Selectors
Message Replay
Structured data types that allow interoperability between various architectures and programming languages
Kerberos authentication
Note that it does not yet support the following features:
Request/Reply message exchange pattern
PubSub+ Cache Client API support
Session Transactions
XA Transactions
Queue browsing
EA Download is attached to this post. Unzip and be sure to read the readme.txt (Don’t worry, it will be available via maven central once GA)
We’re Welcoming feedback during the Early Access period! Feel free to respond in this thread or start a new one. Please tag myself, @amackenzie and/or @Aaron as we’ll be looking for feedback on this new API! You might even get some SWAG solace-messaging-client-0.0.5-dev.584-EA.zip (6.62 MB)
@marc I’m looking to setup my pom file to try out the new API. Do I need both the JCSMP dependency and the solace-messaging-client? If so, why do I need both. Thanks!
@Thrillstone (great username btw) the new Java API is a wrapper for JCSMP and thus needs it as a pom dependency. It’s similar to how the Solace JMS provider is a wrapper for JCSMP and also requires JCSMP as a dependency.
Hey team… I’m whipping up some new samples with the New Java API! It’s definitely different than JCSMP, but I like it a lot… feels very modern. Hoping other people give it a try…! ?
Getting the following error when I try to build the samples via maven:
[ERROR] Failed to execute goal on project solace-messaging-client-sampler: Could not resolve dependencies for project com.solace:solace-messaging-client-sampler:jar:0.0.5-SNAPSHOT: The following artifacts could not be resolved: com.solacesystems:sol-jcsmp:jar:10.9.1-nextGen.41309, com.solace:solace-messaging-client:jar:0.0.5-SNAPSHOT: Could not find artifact com.solacesystems:sol-jcsmp:jar:10.9.1-nextGen.41309 in central (https://repo.maven.apache.org/maven2) -> [Help 1]
hey @GreenRover are you referring to queue creation from the API? You can use the MissingResourcesCreationStrategy method to create a queue if it doesnt exist
Dint found the option to ignore subscription that are already assigned to the queue.
Problem 2:
final PersistentMessageReceiver receiver = service
.createPersistentMessageReceiverBuilder()
.withMissingResourcesCreationStrategy(MissingResourcesCreationStrategy.CREATE_ON_START)
.withSubscriptions(
TopicSubscription.of("demo/foo/>"),
TopicSubscription.of("demo/baa/g*/alpha")
)
.withMessageAutoAcknowledgement()
.withActivationPassivationSupport(stateChangeListener)
.build(Queue.durableExclusiveQueue("demo_queue_name"))
.start();
When switching withMessageAutoAcknowledgement and withActivationPassivationSupport
i get an not helping exception:
Exception in thread “main” java.lang.UnsupportedOperationException: Unsupported property value type com.solace.samples.java.ConsumeQueue$$Lambda$110/0x00000008002d6440
When using the builder/fluent setter pattern, the order how the calling the methods should be irrelevant.
The handling of to big messages is still broken (Ticket RT-55160).
If i send a 31MB message to the broker:
I get in log: ERROR com.solac.messa.publi.PersistentMessagePublisherImpl - DefaultProducer should not be log:null
com.solacesystems.jcsmp.JCSMPErrorResponseException: 400: Document Is Too Large
The 1st 2 look like potential bugs. Can I ask that you log a ticket with Solace Support to get dev to act on them?
The 3rd is (as you have pointed out) a known issue and was not expected to have been fixed with Java API 1.0.0. We are working on addressing this and the fix will also pertain to a subsequent release of the Java API.
@amackenzie Please have your developers to read this. I currently not interested to use the new lib.
I like the new concepts but the current jcsmp looks much more stable.
Just wanted to give a a try an made short testing. I have no official task to evaluate this lib. Just using some spare time and be unable to spend more time for this.
This new Java API is intended to modernize the way developers write Java clients for PubSub+ Event Brokers and will take a builder style approach – similar what our recently released Python API does.