Hi, Do you think there is a way to configure queues and topics in tomee.xml using a property key that contains the destination name ? From what I see, the property key is used to match a setter or field. Any way to write configuration like this ?
queues.foo = read=..., write=..., admin=... queues.myQueue = read=..., write=..., admin=... topics.myTopic = read=..., write=..., admin=... If not, I will have to go with something less readable, something like : queues = foo(read=..., write=..., admin=...), myQueue(read=..., write=..., > admin=...) > topics = myTopic(read=..., write=..., admin=...) Thanks. -- Marian MULLER SERLI On Thu, Jun 5, 2014 at 3:25 PM, Romain Manni-Bucau <[email protected]> wrote: > Basically provide what you need (or what you think you'll need) - and > what you find fun ;). If sby needs more we'll add it later. > > > > > Romain Manni-Bucau > Twitter: @rmannibucau > Blog: http://rmannibucau.wordpress.com/ > LinkedIn: http://fr.linkedin.com/in/rmannibucau > Github: https://github.com/rmannibucau > > > 2014-06-05 15:14 GMT+02:00 Marian Muller <[email protected]>: > > The AuthorizationPlugin would also require to specify the destination > type. > > And maybe the support for temp destinations configuration. > > This plugin also supports different kinds of "authorization maps", > > including LDAP and CachedLDAP. But maybe this is out of the scope for > now. > > > > Regarding the generic resource factory, in the beginning I felt like I > was > > missing this kind of feature. But factories really do the job and allow > to > > customize the configuration. > > Compared to factories, I think a generic resource factory would lead to > > less readable configuration (multiple resources to declare), and - > > depending on the class structure - may not solve all the problems (e.g. > > complex collection attributes, like a Map<String, Set<...>> would still > not > > be supported). > > > > Anyway I will define a configuration/factory for AuthorizationPlugin. > > > > Regarding the factories, do you think this is OK to provide a limited set > > for a few plugins? > > > > -- > > Marian MULLER > > SERLI > > > > > > On Thu, Jun 5, 2014 at 2:38 PM, Romain Manni-Bucau < > [email protected]> > > wrote: > > > >> Depend but if you think to authorizationplugin something like it could > >> work: > >> > >> <Resource id="..." class-name="..."> > >> queue1 = read=user;admins,write=admin;sudo,admin=admin > >> </Resource> > >> > >> We can still support a generic resource factory understading $dddd as > >> a lookup to do on dddd. This way you can wire beans together > >> genericly. > >> > >> That said not sure there are enough specific plugins which would need > it. > >> > >> > >> > >> > >> Romain Manni-Bucau > >> Twitter: @rmannibucau > >> Blog: http://rmannibucau.wordpress.com/ > >> LinkedIn: http://fr.linkedin.com/in/rmannibucau > >> Github: https://github.com/rmannibucau > >> > >> > >> 2014-06-05 14:31 GMT+02:00 Marian Muller <[email protected]>: > >> > Hi, > >> > > >> > Thanks for the tip. Using a factory is the way to go. > >> > After adding a factory/service provider in service-jar.xml, I can use > the > >> > following configuration: > >> > > >> > <Resource id="MyAMQPlugin" type="AMQSimpleAuthenticationPlugin"> > >> >> UserPasswords = user1=password1 \n user2=password2 \n > >> >> manager=password3 > >> >> UserGroups = user1=users \n user2=users \n > manager=users,admin > >> > > >> > # Anonymous access configuration is optional > >> > > >> > AnonymousUser = guest > >> > > >> > AnonymousGroup = guest > >> > > >> > AnonymousAccessAllowed = true > >> > > >> > </Resource> > >> >> <Resource id="MyJmsResourceAdapter" type="ActiveMQResourceAdapter"> > >> >> BrokerXmlConfig = broker:(tcp://localhost:61617) > >> >> ServerUrl = tcp://localhost:61617 > >> >> Plugins = [MyAMQPlugin] > >> >> </Resource> > >> > > >> > > >> > This works well for the SImpleAuthenticationPlugin, and I can set > >> multiple > >> > plugins for a given ActiveMQResourceAdapter. > >> > Now I am having a look at the other ActiveMQ plugins. Some require > much > >> > more complex configuration (e.g. AuthorizationPlugin) and others do > not > >> > even require a factory (e.g. JaasAuthenticationPlugin and its > >> subclasses). > >> > > >> > How do you think this should be made generic to support any plugin ? > >> > Providing a factory for every "built-in" AMQ plugins may be feasible, > but > >> > would certainly be a hassle for a not-so-complete support. And users > >> would > >> > still have to implement a factory for their custom or third-party > >> plugins. > >> > We could also simply provide a limited toolset of factories for > >> > authentication related plugins (without declaring them as service > >> > providers) and write a detailed documentation on how to > >> configure/implement > >> > a custom factory for the other plugins ? > >> > In any case, ActiveMQResourceAdapter would accept any BrokerPlugin > beans, > >> > and set them up in the ActiveMQ broker (which is the part where it > must > >> be > >> > generic!). > >> > > >> > What do you think? > >> > > >> > -- > >> > Marian MULLER > >> > SERLI > >> > > >> > > >> > On Tue, Jun 3, 2014 at 6:34 PM, Romain Manni-Bucau < > >> [email protected]> > >> > wrote: > >> > > >> >> For these advanced cases we provide a factory in openejb users rely > on > >> (all > >> >> container are done this way for instance). So just use the config you > >> want, > >> >> get properties injected in your factory and declare the class-name > >> >> attribute of your resource with the value of the qualified name of > the > >> >> factory. > >> >> > >> >> > >> >> > >> >> 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 18:22 GMT+02:00 Marian Muller <[email protected]>: > >> >> > >> >> > 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 > >> >> > > > > > >> >> > > > > > >> >> > > > > >> >> > > > >> >> > > >> >> > >> >
