You are welcome :) -- Jean-Louis Monteiro http://twitter.com/jlouismonteiro http://www.tomitribe.com
On Thu, Jun 19, 2014 at 3:46 PM, Marian Muller <[email protected]> wrote: > Hi all, > > Just giving you an update. I have been re-assigned to a priority task which > will keep me busy for a little while. > I will come back to you when I can work on this topic again. I am > definitely looking forward to it ! > > Marian. > > -- > Marian MULLER > SERLI > > > On Fri, Jun 6, 2014 at 10:13 AM, Marian Muller <[email protected]> > wrote: > > > 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 > >> > > >> >> > > > > > >> > > >> >> > > > > > >> > > >> >> > > > > >> > > >> >> > > > >> > > >> >> > > >> > > >> >> > >> > > >> > >> > > > >> > > >> > > > > >
