Great ! Thanks for the tip.
-- Marian MULLER SERLI On Fri, Jun 6, 2014 at 10:04 AM, Romain Manni-Bucau <[email protected]> wrote: > In pseudo code you can do: > > class MyFactory { > private Properties properties; // + setter > > public XXX create() { > // use properties to build your instance > // properties will match resources properties > } > } > > > > Romain Manni-Bucau > Twitter: @rmannibucau > Blog: http://rmannibucau.wordpress.com/ > LinkedIn: http://fr.linkedin.com/in/rmannibucau > Github: https://github.com/rmannibucau > > > 2014-06-06 9:52 GMT+02:00 Marian Muller <[email protected]>: > > > 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 > > > >> >> > > > > > > > >> >> > > > > > > > >> >> > > > > > > >> >> > > > > > >> >> > > > > >> >> > > > >> > > > > > >
