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
> > >> >> > > > >
> > >> >> > > > >
> > >> >> > > >
> > >> >> > >
> > >> >> >
> > >> >>
> > >>
> >
>
