Hi Romain, I had a look at the XBean property editors to configure AMQ plugins from TomEE configuration file. I can easily set the userPasswords for the SimpleAuthenticationPlugin class (it is a simple Map<String,String>), but the userGroups property is not as easy (it is a Map<String, Set<Principal>>). Which makes me wonder if XBean properties are appropriate for complex objects like AMQ plugins. I did not yet look at the other plugins, but I guess they could become even more complex that the rather-simple authentication plugin. And is there a way to instantiate such objects using XBean properties without hard-coding converters for plugin-specific classes (like GroupPrincipal, AuthenticationUser, ...).
Thanks. -- Marian MULLER SERLI On Tue, Jun 3, 2014 at 10:26 AM, Romain Manni-Bucau <[email protected]> wrote: > Hi > > I think the solution without activemq.xml is great. We could make a default > jars.txt a user could drop in conf/ to add all the required dependencies if > it helps but putting spring is the container is not a good idea as default > solution. In particular for this case where we know how to get it properly > done. > > Side note: would be great to be able to do a network of brokers between > tomee instances too. > > > > > Romain Manni-Bucau > Twitter: @rmannibucau > Blog: http://rmannibucau.wordpress.com/ > LinkedIn: http://fr.linkedin.com/in/rmannibucau > Github: https://github.com/rmannibucau > > > 2014-06-03 10:23 GMT+02:00 Marian Muller <[email protected]>: > > > Hi Andy, > > > > Thanks for the insight. I think we need to take some time and discuss the > > topic, before going further. > > > > I understand your point about the simple "built-in" solution being what > its > > name suggests: a simple solution for running localhost/vm-only broker. > This > > makes much sense! And I also believe there is a need for a deep > > understanding of ActiveMQ configuration, when addressing more complex > > situations. > > > > I think the activemq.xml file fits this description, however I also think > > the Spring requirement may be a hurdle to some users. The TomEE > > website mentions > > the need for Spring and XBean libraries > > <http://tomee.apache.org/jms-resources-and-mdb-container.html>, yet I > hit > > a > > few issues when following the instructions: > > > > 1/ Adding the 5 mentioned jars (spring-* and xbean-spring) is not enough, > > there is still a ClassNotFoundException > > (org.apache.activemq.xbean.XBeanBrokerFactory) when using > > 'xbean:file:conf/activemq.xml'. It looks like the activemq-spring jar is > > also required here. > > > > 2/ Maybe I missed something here, but I was not able to load the > > activemq.xml file using a relative path as suggested in TomEE > > documentation. I just keep getting a FileNotFoundException. > > > > > > Do you think we could improve the user experience wrt integrating the > > activemq.xml configuration file ? Maybe by making this a bit clearer and > > easier to get all the required dependencies ? > > Adding a way to declare AMQ plugins within tomee configuration file - as > > suggested by previous posts - would also make it simpler for users. > > Although I agree it would be better to stick to AMQ configuration syntax. > > And about point 2, did I miss something ? > > > > Thanks. > > > > -- > > Marian MULLER > > SERLI > > > > > > On Fri, May 30, 2014 at 2:53 PM, Andy Gumbrecht < > [email protected]> > > wrote: > > > > > Hi Marian, > > > > > > I have always been of the opinion that the default configuration is the > > > simple way, and more complex scenarios need a more complex solution, > > > and a really deep understanding of ActiveMQ configuration. > > > > > > The simple solution is seen as a localhost/vm only solution which never > > > goes outside the box - The clients do not see or access the MQ > directly. > > > > > > The complex solutions starts with your scenario - Clients should have > > > remote access and authenticate (and that is a massive step, not to be > > taken > > > lightly). > > > > > > So where to address that? > > > > > > Romain's plugin idea works, but seems like an awful lot of work to > > replace > > > something that is in effect already there - > > > The 'xbean:file:conf/activemq.xml'. > > > > > > I was also initially annoyed by the whole Spring requirement for a > > > 'simple' XML file, but that's an ActiveMQ issue which we have to live > > with > > > if we want to configure it. > > > Once you use it there really is no issue. To add all that endless > > > functionality to OpenEJB is really outside the box in my opinion. A few > > > megs of jars isn't really such a big issue. > > > > > > If you start to dig in to ActiveMQ conf (http://activemq.apache.org/ > > > version-5-xml-configuration.html) then you'll understand why they maybe > > > opted for the Spring XBean configuration. > > > > > > What is your greater picture here? Why do you want to allow remote MQ > > > clients to authenticate? > > > > > > If we start talking about local application authentication then think > > > 'TomEE cluster', then you're only going to have one ActiveMQ server > > > (standalone, and maybe also a cluster) - Aligning authentication with > > TomEE > > > is probably not going to work. > > > > > > A JDBC realm could be a solution - Both servers authenticate can > > > authenticate against it. > > > > > > But really you'd only need one ActiveMQ user/pw per application. > > > > > > Andy. > > > > > > > > > On 30/05/2014 11:35, Marian Muller wrote: > > > > > >> Hi all, > > >> > > >> For starters, let me introduce myself. I am Marian Muller and I work > as > > a > > >> Java EE engineer at SERLI. As part of my job, I will dedicate some > time > > to > > >> contributing to TomEE. > > >> > > >> I am working on a simpler way to configure authentication in the > > embedded > > >> ActiveMQ broker. Currently, you can easily start the embedded broker > > using > > >> just a few lines of xml: > > >> > > >> > > >> <Resource id="MyJmsResourceAdapter" type="ActiveMQResourceAdapter"> > > >>> BrokerXmlConfig = broker:(tcp://someHostName:61616) > > >>> ServerUrl = vm://localhost > > >>> </Resource> > > >>> > > >>> > > >> But if you want to add authentication to the broker, you need to write > > an > > >> ActiveMQ xml configuration file, and - that feels a bit wrong - you > need > > >> to > > >> add Spring and ActiveMQ libraries in TomEE! (see > > >> http://tomee.apache.org/jms-resources-and-mdb-container.html) > > >> > > >> <Resource id="MyJmsResourceAdapter" type="ActiveMQResourceAdapter"> > > >> > > >>> BrokerXmlConfig = xbean:file:conf/activemq.xml > > >>> ServerUrl = tcp://someHostName:61616</Resource> > > >>> > > >>> > > >>> I looked up how the ActiveMQ embedded broker is configured and > > started, > > >> and > > >> I think it should be possible to add an option to the resource adapter > > to > > >> specify basic user/password authentication. Now I am wondering what > this > > >> option should look like ? I see at least three possibilities: > > >> > > >> a) Specify a list of (username/password/groups) directly in the > > >> ResourceAdapter options (in tomee.xml). This feels a bit tedious, > would > > >> clutter the config file and would require to define a specific syntax. > > >> b) Specify the path to a file (xml? properties? ...), containing the > > list > > >> of (username/password/groups). This would lighten the configuration > file > > >> (tomee.xml) by moving away the verbose stuff. > > >> c) Maybe we could reuse the existing user database from > > >> conf/tomcat-users.xml ? This way we only need a single file to > configure > > >> all the users. > > >> > > >> > > >> This is for the simple username/password authentication, which would > use > > >> ActiveMQ's SimpleAuthenticationPlugin. > > >> > > >> Now maybe a better way to add JMS authentication would be to reuse the > > >> existing Realm, which can be configured by the users. This would > > probably > > >> require to write a custom ActiveMQ plugin that checks authentication > > >> against the realm. But this would open much more authentication > options! > > >> Now, if you don't mind, I could use some pointers on how to reuse this > > >> Realm, and also how to define another realm for JMS authentication (if > > the > > >> user wants so)? > > >> To me, this feels like a better way to centralize authentication in > > Tomcat > > >> Realms! > > >> > > >> What do you think? How do you see JMS authentication? > > >> Please tell me if I am going the wrong way here. > > >> I could definitely use the community feedback here! :) > > >> > > >> Thank you. > > >> -- > > >> Marian MULLER > > >> SERLI > > >> > > >> > > > -- > > > Andy Gumbrecht > > > > > > http://www.tomitribe.com > > > [email protected] > > > https://twitter.com/AndyGeeDe > > > > > > TomEE treibt Tomitribe! | http://tomee.apache.org > > > > > > > > >
