The issue is the generator tool relying on the doclet API that wtas removed
in JDK 11+ so to run the current generator we have to run the tool with JDK
8 at build time. We would need to re-write all that parsing with the new
API. https://openjdk.org/jeps/221 Unfortunately trying to update
Hey Chris-
Thanks for taking the first pass in to the generator code.
This got me thinking— Can we make a JDK and tools break to decouple the
complexity that comes with dropping annogen AND trying to maintain JDK 8
support?
We leveled ActiveMQ v6.x to JDK 17— keeping JDK 8 (language) support
I started looking at the Openwire generator issues and the biggest problem
is the use of a super ancient library for things like javadoc parsing which
no longer works on JDK 11+ https://github.com/codehaus/annogen
The entire doclet API was changed so we would need to update the openwire
generator
Hi Chris-
My comments in-line below. For the most part, I agree in full. Any of the work
that we can break up into minor or patch releases would be good from the
standpoint of getting some runtime of all the changes under our belt before
rolling out the major breaking change parts.
> On Dec
+1 on openwire generator code project modernization
> On Dec 4, 2023, at 6:19 AM, Christopher Shannon
> wrote:
>
> Speaking of protocol changes, if we do generate a new openwire version to
> add shared sub commands we have to actually fix the Openwire generator
> including the CVE issue.
>
>
Yup agree and it means a new major version imho.
Le lun. 4 déc. 2023 à 13:19, Christopher Shannon <
christopher.l.shan...@gmail.com> a écrit :
> Speaking of protocol changes, if we do generate a new openwire version to
> add shared sub commands we have to actually fix the Openwire generator
>
We can have a roadmap and targets for things but the main thing I'm pushing
back on is having firm dates as there is a lot of unknown. There is a lot
of work left to do and it will take time to get things correct. We don't
want to have a rushed/bad implementation that is buggy.
For one thing, if
Ok. But in that case, can we target SMX 7 with full JMS 2 support ?
I think it’s important to have a kind of roadmap.
So let’s use 6.x for incremental work and 7 when complete (without strong
commitment on date).
Regards
JB
Le lun. 4 déc. 2023 à 13:18, Christopher Shannon <
Speaking of protocol changes, if we do generate a new openwire version to
add shared sub commands we have to actually fix the Openwire generator
including the CVE issue.
On Mon, Dec 4, 2023 at 7:18 AM Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:
> I don't see how we can release
I don't see how we can release shared subscription support for 6.1.0 at
this point. We haven't even come up with a plan of how we are going to
implement it. There's multiple ways it could be done and probably requires
protocol changes. We have to decide how much work is done by the broker and
I think it would better to complete JMS 2 in 6.1.0 including shared topic
subscriptions.
We already did 6.0.x with partial JMS 2 support, which is so so from user
perspective.
I would prefer to wait few weeks for 6.1.0 to give us time to complete JMS
2.
Regards
JB
Le lun. 4 déc. 2023 à 07:52,
Hey JB --
These JMS 2.0 features are planned for v6.1.0:
AMQ-8464 PR #1046 6.1.0, 5.18.x JMSConsumer .receiveBody(Class) methods
AMQ-8320 PR #982 6.1.0, 5.18.x Delivery Delay Support for Message
DeliveryDelay feature
AMQ-8324 PR #1045 6.1.0, 5.18.x JMSProducer features Completion Listener
That makes sense to me, bugfixes in the 6.0.x patch version and extended
functionality (JMS 2 and perhaps better observability) in 6.1.
I suggest code base modernization might be saved for within the 6.1 series
but not 6.1.0, so we are not mixing new functionality with under the hood
refactoring
Hi
I think it's really important to focus on JMS 2 complete impl for 6.1.0.
That's the most important.
I started to work on some impl, a couple are a little longer to impl,
require tests etc.
I don't think early January is reasonable. I would rather try at the
end of January.
I would rather:
1.
All-
I’ve started organizing some JIRAs for v6.1.0. I’m thinking early-January for
release target timeframe.
- Additional JMS 2.0 impls
- New features for observability
- Code base modernization
Thanks!
Matt Pavlovich
15 matches
Mail list logo
