Re: [PROPOSAL] Change OSGi packaging for ActiveMQ 5.19.x
> I agree with the overhead but is it really an issue Of course it is an issue (depending on how much you embedd), at least it vast disk, cpu, ram and network resources > AMQ broker is a black box in Karaf/OSGi So no configuration? No plugins? No management possible? Client only ever use plain JMS standard API? > nobody is doing Spring update or Jetty update in ActiveMQ without > upgrading the whole ActiveMQ Not in ActiveMQ but in OSGi... so if you require Spring version 9.3 or later and Spring releases 9.3.1 I can upgrade the Spring bundles and I'm done, with uber-jar/bundle/war/... I need to ask for a new ActiveMQ release and then get additional delay even if it would be released fast... > The big advantage is to avoid OSGi coupling at build time > for developers Why should a developer ever be "coupled" to OSGi at build time and why should this change that there is one or multiple bundles? And even for ActiveMQ build itself you can always just generate the OSGi metadata separately and don't need to think about OSGi at all. As Karaf can even wrap bundles dynamically you even don't need OSGi metadata at all for third party libs you depend on. Am 12.09.23 um 07:53 schrieb Jean-Baptiste Onofré: About your points: - I agree with the overhead but is it really an issue ? Having an atomic bundle is not a bad thing imho - that's why I said "most of" import packages and today, AMQ broker is a black box in Karaf/OSGi, so I don't see a difference here - nobody is doing Spring update or Jetty update in ActiveMQ without upgrading the whole ActiveMQ, and actually I think it's a good thing as it's more predictable - I'm not sure projects actually really try and it really depends of the use case. Definitely for a library it's not a good approach, but for "middleware" like AMQ it works fine. I experimented with the same approach for Camel components and it works just fine. The big advantage is to avoid OSGi coupling at build time for developers (else the consequence will be that OSGi will be just removed from the project like in Camel 4). Just background: today, ActiveMQ 5.19.x (or 6.x :)) requires updates that are not yet available in OSGi/Karaf (Spring 6, Jetty 11, jakarta, ..., even if I rushed to provide the SMX bundles required for that, but it also needs JDK17+). So, as I want to release this new major AMQ version soon, I have to find a more sustainable approach (to avoid 5+ external releases just for OSGi). Regards JB On Tue, Sep 12, 2023 at 6:26 AM Christoph Läubrich wrote: > I disagree on what particular point? > I don't understand why people are against uber bundle. Because it has many bad properties: - You duplicate the code in your bundle, especially for large frameworks like spring this can be a major overhead, if someone else is using that framework it will be loaded effectively twice (or three time or four if other follow your example) - You will expose your code to subtile class space problem, how will you test/ensure that none of the "private" dependencies will ever leak to the outside if you still want to allow collaboration? - Every update to a dependency will require a full ActiveMQ release as it is no longer possible to upgrade the dependency independently - I don't know any project that followed this path with success, felix-http even has dropped now their support for embedded jetty (what is one of the rare case where this could work quite well). Am 12.09.23 um 06:15 schrieb Jean-Baptiste Onofré: Hi, I disagree, I don't understand why people are against uber bundle. The export packages stay the same, so ActiveMQ can still "collaborate" with other bundles. Most of import (not all) will go private, not necessary all (I'm on a PoC right now). Regards JB On Tue, Sep 12, 2023 at 5:48 AM Christoph Läubrich wrote: Making "uberbundles" is really bad not only for file-size, OSGi was made with sharing in mind and embedding "everything" will make this impossible if you not at the same time rexport the packages what has other implications. Also keep in mind that he activemq could not participate in any other things so it never should expose any object from "inside" to the user code, also if you now has a refresh you replace these (local) refreshes with one big classloader that looses all its state at once, not sure if this is better here. If you want to avoid such issues it is generally better to reduce the dependency count, e.g. check if this SMX bundles are really required or if they are just used for historic reasons (e.g many things today can be replaced by standard java features). Regarding coupling "OSGi with Karaf" I know for sure some projects using activemq without karaf, so this is again just a convenience thing, it is easier to use with a karaf feature, but if you have
Re: [PROPOSAL] Change OSGi packaging for ActiveMQ 5.19.x
> I disagree on what particular point? > I don't understand why people are against uber bundle. Because it has many bad properties: - You duplicate the code in your bundle, especially for large frameworks like spring this can be a major overhead, if someone else is using that framework it will be loaded effectively twice (or three time or four if other follow your example) - You will expose your code to subtile class space problem, how will you test/ensure that none of the "private" dependencies will ever leak to the outside if you still want to allow collaboration? - Every update to a dependency will require a full ActiveMQ release as it is no longer possible to upgrade the dependency independently - I don't know any project that followed this path with success, felix-http even has dropped now their support for embedded jetty (what is one of the rare case where this could work quite well). Am 12.09.23 um 06:15 schrieb Jean-Baptiste Onofré: Hi, I disagree, I don't understand why people are against uber bundle. The export packages stay the same, so ActiveMQ can still "collaborate" with other bundles. Most of import (not all) will go private, not necessary all (I'm on a PoC right now). Regards JB On Tue, Sep 12, 2023 at 5:48 AM Christoph Läubrich wrote: Making "uberbundles" is really bad not only for file-size, OSGi was made with sharing in mind and embedding "everything" will make this impossible if you not at the same time rexport the packages what has other implications. Also keep in mind that he activemq could not participate in any other things so it never should expose any object from "inside" to the user code, also if you now has a refresh you replace these (local) refreshes with one big classloader that looses all its state at once, not sure if this is better here. If you want to avoid such issues it is generally better to reduce the dependency count, e.g. check if this SMX bundles are really required or if they are just used for historic reasons (e.g many things today can be replaced by standard java features). Regarding coupling "OSGi with Karaf" I know for sure some projects using activemq without karaf, so this is again just a convenience thing, it is easier to use with a karaf feature, but if you have other deployment targets why not check what they use and make it convenient there as well? Am 11.09.23 um 14:07 schrieb Jean-Baptiste Onofré: Hi all, As you know, ActiveMQ 5.19.x is in preparation with importants changes: JMS 2, Jakarta namespace, Spring 6, ... For ActiveMQ 5.19.x, I propose to change the OSGi packaging (client and broker). Today we have OSGi bundles for client and broker, with Karaf features installing all dependent features/bundles (spring, commons-*, etc). This approach has few issues: - any update requires SMX bundles or Karaf features, coupling ActiveMQ OSGi with Karaf (jetty, spring, ...) - it's very hard to install ActiveMQ OSGi without Karaf - we can have some side effects depending of what's installed in the Karaf runtime (we already had refresh issues in the past, amd cascading refresh) My proposal is to use a new uber bundle approach for ActiveMQ OSGi client and broker. The idea is to provide OSGi bundles that self-contains everything needed to use/run ActiveMQ. The export packages are the same, but the import packages will be very minimal, most the packages will go private. The advantage is that ActiveMQ OSGi doesn't depend on anything at runtime, it's just a single bundle to install (one bundle for client, one bundle for broker), no extra dependency (so not release dependencies like ServiceMix Bundles or Karaf features), dedicated classloader avoiding refreshes, etc. The only drawbacks are the size of the ActiveMQ client & broker bundles (as they ship other packages, is it really a big deal ?) and the fact that ActiveMQ won't share packages with other bundles (I'm thinking about Spring bundles for instance). It's basically using something similar to the apache-activemq distribution but in OSGi/Karaf. Thoughts ? Regards JB
Re: [PROPOSAL] Change OSGi packaging for ActiveMQ 5.19.x
Making "uberbundles" is really bad not only for file-size, OSGi was made with sharing in mind and embedding "everything" will make this impossible if you not at the same time rexport the packages what has other implications. Also keep in mind that he activemq could not participate in any other things so it never should expose any object from "inside" to the user code, also if you now has a refresh you replace these (local) refreshes with one big classloader that looses all its state at once, not sure if this is better here. If you want to avoid such issues it is generally better to reduce the dependency count, e.g. check if this SMX bundles are really required or if they are just used for historic reasons (e.g many things today can be replaced by standard java features). Regarding coupling "OSGi with Karaf" I know for sure some projects using activemq without karaf, so this is again just a convenience thing, it is easier to use with a karaf feature, but if you have other deployment targets why not check what they use and make it convenient there as well? Am 11.09.23 um 14:07 schrieb Jean-Baptiste Onofré: Hi all, As you know, ActiveMQ 5.19.x is in preparation with importants changes: JMS 2, Jakarta namespace, Spring 6, ... For ActiveMQ 5.19.x, I propose to change the OSGi packaging (client and broker). Today we have OSGi bundles for client and broker, with Karaf features installing all dependent features/bundles (spring, commons-*, etc). This approach has few issues: - any update requires SMX bundles or Karaf features, coupling ActiveMQ OSGi with Karaf (jetty, spring, ...) - it's very hard to install ActiveMQ OSGi without Karaf - we can have some side effects depending of what's installed in the Karaf runtime (we already had refresh issues in the past, amd cascading refresh) My proposal is to use a new uber bundle approach for ActiveMQ OSGi client and broker. The idea is to provide OSGi bundles that self-contains everything needed to use/run ActiveMQ. The export packages are the same, but the import packages will be very minimal, most the packages will go private. The advantage is that ActiveMQ OSGi doesn't depend on anything at runtime, it's just a single bundle to install (one bundle for client, one bundle for broker), no extra dependency (so not release dependencies like ServiceMix Bundles or Karaf features), dedicated classloader avoiding refreshes, etc. The only drawbacks are the size of the ActiveMQ client & broker bundles (as they ship other packages, is it really a big deal ?) and the fact that ActiveMQ won't share packages with other bundles (I'm thinking about Spring bundles for instance). It's basically using something similar to the apache-activemq distribution but in OSGi/Karaf. Thoughts ? Regards JB
Re: [DISCUSS] Use a generic logger in ActiveMQ Artemis
SLF4J support the "Mapped Diagnostic Context" maybe this would be a good replacement here? you could even add more context infos then and people are free to format them as they like: https://logback.qos.ch/manual/mdc.html Am 03.05.22 um 22:30 schrieb Justin Bertram: The point here is that the current logging implementation provides a simple way to associate codes with each user-facing log message and exception. This is helpful to those who may want to monitor logs for certain codes (e.g. for alerting purposes), filter some codes out, etc. In this way the logging is part of a contract with the users much like an API is a contract with developers. The codes stay consistent across versions but the content of the message may change (e.g. to provide more information, correct spelling errors, typos, etc.). This kind of facade also opens the door for fairly simple internationalization. The goals here as I see them: - Maintain the aforementioned functionality. - Ditch the dependence on JBoss Log Manager and JBoss Logging. Having a simple implementation of our own is an easy way to do this. If we decide to go this route then (and only then) we will need to decide on the underlying logging facade and implementation. Justin On Tue, May 3, 2022 at 3:17 PM Christopher Shannon < christopher.l.shan...@gmail.com> wrote: Using SL4J makes sense to me as that is what almost everyone else uses so it's pretty standard and easy to swap implementations On Mon, May 2, 2022 at 1:26 PM Justin Bertram wrote: I think this looks great, Clebert. The code is straightforward, and I like the idea of reducing our dependencies. This is a +1 from me. Justin On Fri, Apr 29, 2022 at 3:43 PM Clebert Suconic < clebert.suco...@gmail.com wrote: For a while, I thought it would be nice to remove jboss-logging from artemis and use a generic logger. (SLF4J, Log4j, commons.. whatever.. it's all orthogonal and transparent to this discussion, we can decide that at a later point). One of the issues we had while making the move would be the generated error codes out of the Log Processor. So, I put together a prototype here that would generate code based on an interface and that could use whatever logger we choose. I will try to never remove the branch for future reference: https://github.com/clebertsuconic/activemq-artemis/tree/prototype-log-processor the Log processor would read the annotations and generate the code: https://github.com/clebertsuconic/activemq-artemis/blob/prototype-log-processor/artemis-log-processor/src/main/java/org/apache/activemq/artemis/logprocessor/processor/LogProcessor.java A testcase here would show how such processing would work: https://github.com/clebertsuconic/activemq-artemis/blob/prototype-log-processor/artemis-log-processor/src/test/java/org/apache/activemq/i18n/test/SimpleBundleTest.java I have added some code on the artemis-server, trying to simulate what we would do in "real life": https://github.com/clebertsuconic/activemq-artemis/blob/prototype-log-processor/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/ActiveMQServerNewLogger.java This test here is making a call to the NewLogger, just to show how processing would work. Everything would work just like it would now: https://github.com/clebertsuconic/activemq-artemis/blob/prototype-log-processor/artemis-server/src/test/java/org/apache/activemq/artemis/core/TestSample.java I would appreciate some feedback if this is a good way forward or not... (please let's not diverge on what logging framework we are choosing now... that's a separate discussion). -- Clebert Suconic
Re: I need help with Karaf / Artemis features
It seems org.apache.activemq.artemis-server-osgi requires the package
org.glassfish.json
this was probably provided previously by some of the now excluded
dependencies.
Am 12.11.21 um 22:11 schrieb Clebert Suconic:
If you don't want to read the whole message: TL;DR: I need help with
this Pull Request:
https://github.com/apache/activemq-artemis/pull/3846
Artemis-features is failing with some lack of json support:
Long form:
To solve a clash between javax and jakarta users, I'm simply now
removing javax.json by shading javax.json and johnzon into
artemis-commons.
I pretty much removed every reference to json from the codebase, and
everything is just using artemis-commons.
However, artemis-features now is not working at all:
if you download the branch above, and do this:
cd artemis-features
mvn install
you will get these errors:
[ERROR] Message: Unable to resolve root: missing requirement [root]
osgi.identity; osgi.identity=artemis-openwire; type=karaf.feature;
version=2.20.0.SNAPSHOT;
filter:="(&(osgi.identity=artemis-openwire)(type=karaf.feature)(version>=2.20.0.SNAPSHOT))"
[caused by: Unable to resolve artemis-openwire/2.20.0.SNAPSHOT:
missing requirement [artemis-openwire/2.20.0.SNAPSHOT] osgi.identity;
osgi.identity=artemis-core; type=karaf.feature [caused by: Unable to
resolve artemis-core/2.20.0.SNAPSHOT: missing requirement
[artemis-core/2.20.0.SNAPSHOT] osgi.identity;
osgi.identity=org.apache.activemq.artemis-server-osgi;
type=osgi.bundle; version="[2.20.0.SNAPSHOT,2.20.0.SNAPSHOT]";
resolution:=mandatory [caused by: Unable to resolve
org.apache.activemq.artemis-server-osgi/2.20.0.SNAPSHOT: missing
requirement [org.apache.activemq.artemis-server-osgi/2.20.0.SNAPSHOT]
osgi.wiring.package;
filter:="(osgi.wiring.package=org.glassfish.json)"]]]
[ERROR] Repositories: {
[ERROR]
file:/Users/clebertsuconic/work/apache/activemq-artemis/artemis-features/target/classes/features.xml
[ERROR] mvn:org.apache.aries.jpa/jpa-features/2.7.3/xml/features
[ERROR] mvn:org.apache.karaf.features/enterprise/4.3.3/xml/features
[ERROR] mvn:org.apache.karaf.features/framework/4.3.3/xml/features
[ERROR] mvn:org.apache.karaf.features/specs/4.3.3/xml/features
that i have no idea how to fix it...
HELP
JMS Mix "Classic" Clients with "Artemis" Servers
We currently plan to switch from Classic>Artemis but there is one point not completely clear (or I have missed something?), is it possible to connect with a "activemq classic" JMSConnectionFactory to an artemis server (given that they both enable the tcp transport of course, same host and port etc...) So we can switch the server to "Artemis" and then upgrade the (classic) clients step-by-step?
Re: [HEADS-UP] ActiveMQ Artemis Release some time after next week
Just in case I missed it, is the release out already? Am 17.05.21 um 20:23 schrieb Clebert Suconic: I got stuck into an issue at work... and I'm reviewing my schedule now... I will update it later this week... sorry about any inconvenience. On Mon, May 17, 2021 at 5:55 AM Christoph Läubrich wrote: Are there any schedule for the new release? Am 22.04.21 um 01:15 schrieb Clebert Suconic: I'm being very meticulous on my testing with AMQP Mirror (it's getting out in a good shape).. and I'm pushing the release back for a week. (the PR is in good shape for a review already: https://github.com/apache/activemq-artemis/pull/3545 and i would appreciate reviews) I'm adding tests and fixing minor things now... and I plan to release as soon as this is merged. I'm also pending on ARTEMIS-3241 for the release... please here with any progress as the release is depending on that as well. On Tue, Apr 13, 2021 at 1:45 PM Robbie Gemmell wrote: The LICENSE file in the binary archive came up in some changes in a recent PR, and it became clear it needs an overhaul for improper (and possibly stale) console deps entries. I raised https://issues.apache.org/jira/browse/ARTEMIS-3241 to track that for the folks familiar with the console bits. I just looked and the NOTICE file its date is stale, I've just updated that myself as the change needed is fairly obvious: https://github.com/apache/activemq-artemis/commit/d6ee91a50591e37ccf5e3a630b2bfdc2c8ed47bd Robbie On Fri, 9 Apr 2021 at 15:56, Clebert Suconic wrote: I plan a release some time after the middle of next week. I am working on an improvement over broker connections, and I would like to push a release after I'm finished, what should happen around next Wednesday. I will update here with a more precise date when I'm finished with my current task. -- Clebert Suconic
Re: [HEADS-UP] ActiveMQ Artemis Release some time after next week
Are there any schedule for the new release? Am 22.04.21 um 01:15 schrieb Clebert Suconic: I'm being very meticulous on my testing with AMQP Mirror (it's getting out in a good shape).. and I'm pushing the release back for a week. (the PR is in good shape for a review already: https://github.com/apache/activemq-artemis/pull/3545 and i would appreciate reviews) I'm adding tests and fixing minor things now... and I plan to release as soon as this is merged. I'm also pending on ARTEMIS-3241 for the release... please here with any progress as the release is depending on that as well. On Tue, Apr 13, 2021 at 1:45 PM Robbie Gemmell wrote: The LICENSE file in the binary archive came up in some changes in a recent PR, and it became clear it needs an overhaul for improper (and possibly stale) console deps entries. I raised https://issues.apache.org/jira/browse/ARTEMIS-3241 to track that for the folks familiar with the console bits. I just looked and the NOTICE file its date is stale, I've just updated that myself as the change needed is fairly obvious: https://github.com/apache/activemq-artemis/commit/d6ee91a50591e37ccf5e3a630b2bfdc2c8ed47bd Robbie On Fri, 9 Apr 2021 at 15:56, Clebert Suconic wrote: I plan a release some time after the middle of next week. I am working on an improvement over broker connections, and I would like to push a release after I'm finished, what should happen around next Wednesday. I will update here with a more precise date when I'm finished with my current task. -- Clebert Suconic
Re: [HEADS-UP] Artemis release next week..
The changes are rather small and local nothing real big, I'll prepare the PR tomorrow it might be easier to judge then. I'll try to provide an example demonstration SASL-SCRAM with Apache cupid client along with the PR do demonstrate the usage! Am 04.02.21 um 19:40 schrieb Clebert Suconic: It depends on the size of the PR. If it's something simple, low risk I would say we can wait for it.. however if it's something major and has some risk, I would prefer having a lot of full testsuite runs (that I do on a CI I have access) between when a major PR is merged and a release. if you're adding a service loader without changing much at the server dependencies we can merge it... otherwise we can wait another release. (we don't need to wait 2 months for another release... we can make another whenever needed). On Thu, Feb 4, 2021 at 10:43 AM Christoph Läubrich wrote: It might be too late, but I'm currently investigate in an issue related to [1] and like to provide a PR the next days that add support of providing sasl mechanism through java-service-loader is there any chance (assuming I got everything done in time) to include this in the next release? [1] https://issues.apache.org/jira/browse/ARTEMIS-33 Am 04.02.21 um 16:36 schrieb Clebert Suconic: everythign is merged... There is one final issue I'm after though.. .I have made libaio to close files asynchronously. I have seen an eventual failure on the testsuite (well, a warning to be more precise) on waiting to close files... that I am after. I will postpone this release to monday to give me time to find that issue before I release. Sorry for any inconvenience. On Mon, Feb 1, 2021 at 3:42 AM Emmanuel Hugonnet wrote: Hello, It would be nice if we could have https://github.com/apache/activemq-artemis/pull/3412 in this release :) Cheers, Emmanuel Le 29/01/2021 à 17:53, Clebert Suconic a écrit : I plan to do an artemis release some time next week (around Wed) I will check on pending PRs... (please give me a hand also on merging stuff) if there's anything you need my attention on a particular PR please mention it here on this thread.. I will make sure we merge the Jakarta integration before this release BTW. I am also postponing JDK upgrade for a release after this, given Wildfly (Emmanuel) request to keep the next release as JDK 8 due to JavaEE needs. -- Clebert Suconic
Re: [HEADS-UP] Artemis release next week..
It might be too late, but I'm currently investigate in an issue related to [1] and like to provide a PR the next days that add support of providing sasl mechanism through java-service-loader is there any chance (assuming I got everything done in time) to include this in the next release? [1] https://issues.apache.org/jira/browse/ARTEMIS-33 Am 04.02.21 um 16:36 schrieb Clebert Suconic: everythign is merged... There is one final issue I'm after though.. .I have made libaio to close files asynchronously. I have seen an eventual failure on the testsuite (well, a warning to be more precise) on waiting to close files... that I am after. I will postpone this release to monday to give me time to find that issue before I release. Sorry for any inconvenience. On Mon, Feb 1, 2021 at 3:42 AM Emmanuel Hugonnet wrote: Hello, It would be nice if we could have https://github.com/apache/activemq-artemis/pull/3412 in this release :) Cheers, Emmanuel Le 29/01/2021 à 17:53, Clebert Suconic a écrit : I plan to do an artemis release some time next week (around Wed) I will check on pending PRs... (please give me a hand also on merging stuff) if there's anything you need my attention on a particular PR please mention it here on this thread.. I will make sure we merge the Jakarta integration before this release BTW. I am also postponing JDK upgrade for a release after this, given Wildfly (Emmanuel) request to keep the next release as JDK 8 due to JavaEE needs.
Re: Running Embedded server fails
Thanks a lot seems I got this messed up, referencing *artemis-server* instead works :-) Am 04.02.21 um 15:36 schrieb Robbie Gemmell: That is the pom for the module used to create the distribution archives, I wouldn't really expect an application build to ever use that. Sounds like you want at least artemis-server (as a regular jar type dependency), perhaps others. On Thu, 4 Feb 2021 at 13:40, Christoph Läubrich wrote: I'm using the following dependency so a plain vanilla artemis: org.apache.activemq apache-artemis 2.16.0 pom the code is the one from the link with XML configuration file provided there. My next goal would be using a private build snapshot but of course first I'd like to get a very basic setup working. Am 04.02.21 um 14:34 schrieb Jean-Baptiste Onofre: Oh, sorry, you mean directly, not in Karaf. My bad. Regards JB Le 4 févr. 2021 à 14:31, Christoph Läubrich a écrit : I try to run an embedded server like described in this example [1] but getting the following error, is there anything missing on my side? Runtime is maven with java 11, no compile errors... java.lang.NoSuchMethodError: org.apache.activemq.artemis.utils.uri.BeanSupport.registerConverter(Lorg/apache/commons/beanutils/Converter;Ljava/lang/Class;)V at org.apache.activemq.artemis.core.server.cluster.impl.MessageLoadBalancingType.(MessageLoadBalancingType.java:27) at org.apache.activemq.artemis.core.postoffice.impl.BindingsImpl.(BindingsImpl.java:71) at org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl.createBindings(PostOfficeImpl.java:1931) at org.apache.activemq.artemis.core.postoffice.impl.SimpleAddressManager.addMappingInternal(SimpleAddressManager.java:259) at org.apache.activemq.artemis.core.postoffice.impl.SimpleAddressManager.addBinding(SimpleAddressManager.java:98) at org.apache.activemq.artemis.core.postoffice.impl.WildcardAddressManager.addBinding(WildcardAddressManager.java:95) at org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl.addBinding(PostOfficeImpl.java:873) at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createQueue(ActiveMQServerImpl.java:3771) at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createQueue(ActiveMQServerImpl.java:3703) at org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.createQueue(ServerSessionImpl.java:739) at org.apache.activemq.artemis.core.protocol.core.ServerSessionPacketHandler.slowPacketHandler(ServerSessionPacketHandler.java:371) at org.apache.activemq.artemis.core.protocol.core.ServerSessionPacketHandler.onMessagePacket(ServerSessionPacketHandler.java:292) at org.apache.activemq.artemis.utils.actors.Actor.doTask(Actor.java:33) at org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:65) at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42) at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31) at org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:65) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118) Exception in thread "main" ActiveMQInternalErrorException[errorType=INTERNAL_ERROR message=null] at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:540) at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:434) at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSessionContext.createQueue(ActiveMQSessionContext.java:821) at org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.internalCreateQueue(ClientSessionImpl.java:2038) at org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.createQueue(ClientSessionImpl.java:304) at artemis.TestServer.main(TestServer.java:22) [1] https://activemq.apache.org/components/artemis/documentation/latest/embedding-activemq.html
Re: Running Embedded server fails
the problem can be reproduced by this simple line in a main class: MessageLoadBalancingType type = MessageLoadBalancingType.OFF; I checked the dependencies but can't find anything unusual, any hint would be appreciated. Am 04.02.21 um 14:40 schrieb Christoph Läubrich: I'm using the following dependency so a plain vanilla artemis: org.apache.activemq apache-artemis 2.16.0 pom the code is the one from the link with XML configuration file provided there. My next goal would be using a private build snapshot but of course first I'd like to get a very basic setup working. Am 04.02.21 um 14:34 schrieb Jean-Baptiste Onofre: Oh, sorry, you mean directly, not in Karaf. My bad. Regards JB Le 4 févr. 2021 à 14:31, Christoph Läubrich a écrit : I try to run an embedded server like described in this example [1] but getting the following error, is there anything missing on my side? Runtime is maven with java 11, no compile errors... java.lang.NoSuchMethodError: org.apache.activemq.artemis.utils.uri.BeanSupport.registerConverter(Lorg/apache/commons/beanutils/Converter;Ljava/lang/Class;)V at org.apache.activemq.artemis.core.server.cluster.impl.MessageLoadBalancingType.(MessageLoadBalancingType.java:27) at org.apache.activemq.artemis.core.postoffice.impl.BindingsImpl.(BindingsImpl.java:71) at org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl.createBindings(PostOfficeImpl.java:1931) at org.apache.activemq.artemis.core.postoffice.impl.SimpleAddressManager.addMappingInternal(SimpleAddressManager.java:259) at org.apache.activemq.artemis.core.postoffice.impl.SimpleAddressManager.addBinding(SimpleAddressManager.java:98) at org.apache.activemq.artemis.core.postoffice.impl.WildcardAddressManager.addBinding(WildcardAddressManager.java:95) at org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl.addBinding(PostOfficeImpl.java:873) at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createQueue(ActiveMQServerImpl.java:3771) at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createQueue(ActiveMQServerImpl.java:3703) at org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.createQueue(ServerSessionImpl.java:739) at org.apache.activemq.artemis.core.protocol.core.ServerSessionPacketHandler.slowPacketHandler(ServerSessionPacketHandler.java:371) at org.apache.activemq.artemis.core.protocol.core.ServerSessionPacketHandler.onMessagePacket(ServerSessionPacketHandler.java:292) at org.apache.activemq.artemis.utils.actors.Actor.doTask(Actor.java:33) at org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:65) at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42) at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31) at org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:65) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118) Exception in thread "main" ActiveMQInternalErrorException[errorType=INTERNAL_ERROR message=null] at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:540) at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:434) at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSessionContext.createQueue(ActiveMQSessionContext.java:821) at org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.internalCreateQueue(ClientSessionImpl.java:2038) at org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.createQueue(ClientSessionImpl.java:304) at artemis.TestServer.main(TestServer.java:22) [1] https://activemq.apache.org/components/artemis/documentation/latest/embedding-activemq.html
Re: Running Embedded server fails
I'm using the following dependency so a plain vanilla artemis: org.apache.activemq apache-artemis 2.16.0 pom the code is the one from the link with XML configuration file provided there. My next goal would be using a private build snapshot but of course first I'd like to get a very basic setup working. Am 04.02.21 um 14:34 schrieb Jean-Baptiste Onofre: Oh, sorry, you mean directly, not in Karaf. My bad. Regards JB Le 4 févr. 2021 à 14:31, Christoph Läubrich a écrit : I try to run an embedded server like described in this example [1] but getting the following error, is there anything missing on my side? Runtime is maven with java 11, no compile errors... java.lang.NoSuchMethodError: org.apache.activemq.artemis.utils.uri.BeanSupport.registerConverter(Lorg/apache/commons/beanutils/Converter;Ljava/lang/Class;)V at org.apache.activemq.artemis.core.server.cluster.impl.MessageLoadBalancingType.(MessageLoadBalancingType.java:27) at org.apache.activemq.artemis.core.postoffice.impl.BindingsImpl.(BindingsImpl.java:71) at org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl.createBindings(PostOfficeImpl.java:1931) at org.apache.activemq.artemis.core.postoffice.impl.SimpleAddressManager.addMappingInternal(SimpleAddressManager.java:259) at org.apache.activemq.artemis.core.postoffice.impl.SimpleAddressManager.addBinding(SimpleAddressManager.java:98) at org.apache.activemq.artemis.core.postoffice.impl.WildcardAddressManager.addBinding(WildcardAddressManager.java:95) at org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl.addBinding(PostOfficeImpl.java:873) at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createQueue(ActiveMQServerImpl.java:3771) at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createQueue(ActiveMQServerImpl.java:3703) at org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.createQueue(ServerSessionImpl.java:739) at org.apache.activemq.artemis.core.protocol.core.ServerSessionPacketHandler.slowPacketHandler(ServerSessionPacketHandler.java:371) at org.apache.activemq.artemis.core.protocol.core.ServerSessionPacketHandler.onMessagePacket(ServerSessionPacketHandler.java:292) at org.apache.activemq.artemis.utils.actors.Actor.doTask(Actor.java:33) at org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:65) at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42) at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31) at org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:65) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118) Exception in thread "main" ActiveMQInternalErrorException[errorType=INTERNAL_ERROR message=null] at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:540) at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:434) at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSessionContext.createQueue(ActiveMQSessionContext.java:821) at org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.internalCreateQueue(ClientSessionImpl.java:2038) at org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.createQueue(ClientSessionImpl.java:304) at artemis.TestServer.main(TestServer.java:22) [1] https://activemq.apache.org/components/artemis/documentation/latest/embedding-activemq.html
Running Embedded server fails
I try to run an embedded server like described in this example [1] but getting the following error, is there anything missing on my side? Runtime is maven with java 11, no compile errors... java.lang.NoSuchMethodError: org.apache.activemq.artemis.utils.uri.BeanSupport.registerConverter(Lorg/apache/commons/beanutils/Converter;Ljava/lang/Class;)V at org.apache.activemq.artemis.core.server.cluster.impl.MessageLoadBalancingType.(MessageLoadBalancingType.java:27) at org.apache.activemq.artemis.core.postoffice.impl.BindingsImpl.(BindingsImpl.java:71) at org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl.createBindings(PostOfficeImpl.java:1931) at org.apache.activemq.artemis.core.postoffice.impl.SimpleAddressManager.addMappingInternal(SimpleAddressManager.java:259) at org.apache.activemq.artemis.core.postoffice.impl.SimpleAddressManager.addBinding(SimpleAddressManager.java:98) at org.apache.activemq.artemis.core.postoffice.impl.WildcardAddressManager.addBinding(WildcardAddressManager.java:95) at org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl.addBinding(PostOfficeImpl.java:873) at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createQueue(ActiveMQServerImpl.java:3771) at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createQueue(ActiveMQServerImpl.java:3703) at org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.createQueue(ServerSessionImpl.java:739) at org.apache.activemq.artemis.core.protocol.core.ServerSessionPacketHandler.slowPacketHandler(ServerSessionPacketHandler.java:371) at org.apache.activemq.artemis.core.protocol.core.ServerSessionPacketHandler.onMessagePacket(ServerSessionPacketHandler.java:292) at org.apache.activemq.artemis.utils.actors.Actor.doTask(Actor.java:33) at org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:65) at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42) at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31) at org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:65) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118) Exception in thread "main" ActiveMQInternalErrorException[errorType=INTERNAL_ERROR message=null] at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:540) at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:434) at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSessionContext.createQueue(ActiveMQSessionContext.java:821) at org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.internalCreateQueue(ClientSessionImpl.java:2038) at org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.createQueue(ClientSessionImpl.java:304) at artemis.TestServer.main(TestServer.java:22) [1] https://activemq.apache.org/components/artemis/documentation/latest/embedding-activemq.html
