We could support both options of course ?


On 15 November 2012 06:33, Daniel Bevenius <daniel.bevenius@gmail.com> wrote:
>Dan, for all effects this forum is dead for good :)
Not completely dead yet, there was one reply in favour of CDI ;)




On 14 November 2012 18:00, Douglas Campos <qmx@qmx.me> wrote:
Dan, for all effects this forum is dead for good :)

This ML is our forum :)

On Nov 14, 2012, at 11:44 AM, Daniel Bevenius wrote:

> I've asked this in the user forum too:
> https://community.jboss.org/thread/213370?tstart=0
>
>
> On 14 November 2012 14:33, Matthias Wessendorf <matzew@apache.org> wrote:
> there is pros and cons in both (think spring (java config VS verbose xml)
>
> I guess if we keep it minimal a xml file is fine...
>
> -M
>
> On Wed, Nov 14, 2012 at 2:22 PM, Daniel Bevenius
> <daniel.bevenius@gmail.com> wrote:
> > Thanks for the feedback guys!
> > Going to wait a little longer so everyone who wants to can have a say.
> >
> >
> > On 14 November 2012 14:16, Sebastien Blanc <scm.blanc@gmail.com> wrote:
> >>
> >> Hi firends,
> >> My preference goes for XML config. CORS is more a "external" config aspect
> >> rather than being part of the "domain/core".
> >> Seb
> >>
> >>
> >>
> >> On Wed, Nov 14, 2012 at 12:26 PM, Bruno Oliveira <bruno@abstractj.org>
> >> wrote:
> >>>
> >>> Hi my friend, at first glance looks like the XML option is more readable.
> >>>
> >>> But before we move forward I'd like to hear more opinions about it.
> >>>
> >>>
> >>> --
> >>> "The measure of a man is what he does with power" - Plato
> >>> -
> >>> @abstractj
> >>> -
> >>> Volenti Nihil Difficile
> >>>
> >>>
> >>>
> >>> On Tuesday, November 13, 2012 at 2:15 PM, Daniel Bevenius wrote:
> >>>
> >>> > To help clarify the options here the following gist contains examples
> >>> > of the two suggestions provided so far:
> >>> > https://gist.github.com/4066691
> >>> >
> >>> >
> >>> >
> >>> >
> >>> > On 13 November 2012 16:49, Daniel Bevenius <daniel.bevenius@gmail.com
> >>> > (mailto:daniel.bevenius@gmail.com)> wrote:
> >>> > > > i dislike xml configuration files, so i would vote for an
> >>> > > > Annotation.
> >>> > >
> >>> > > Yeah, I agree and we are avoiding any xml right now.
> >>> > > So, how about we provide some hopefully good defaults for CORS and
> >>> > > then users can provide there own @Producer. We will provide at builder api
> >>> > > to create the config instance so it won't be a lot of work for users.
> >>> > >
> >>> > > Should CORS be enabled by default?
> >>> > >
> >>> > >
> >>> > > On 13 November 2012 13:35, Lucas Holmquist <lholmqui@redhat.com
> >>> > > (mailto:lholmqui@redhat.com)> wrote:
> >>> > > >
> >>> > > > On Nov 13, 2012, at 4:18 AM, Daniel Bevenius
> >>> > > > <daniel.bevenius@gmail.com (mailto:daniel.bevenius@gmail.com)> wrote:
> >>> > > > > I'm working on adding CORS support there are several things that
> >>> > > > > can be configured in this case. Below is an example of the options that are
> >>> > > > > currently available:
> >>> > > > > public interface CorsConfiguration {
> >>> > > > > public abstract boolean isCorsSupportEnabled();
> >>> > > > > public abstract boolean exposeHeaders();
> >>> > > > > public abstract String getExposeHeaders();
> >>> > > > > public abstract boolean anyOrigin();
> >>> > > > > public abstract boolean allowCookies();
> >>> > > > > public abstract boolean hasMaxAge();
> >>> > > > > public abstract long getMaxAge();
> >>> > > > > public abstract Set<String> getValidRequestMethods();
> >>> > > > > public abstract Set<String> getValidRequestHeaders();
> >>> > > > > }
> >>> > > > > How do we want users to configure these configuration options?
> >>> > > > > Using a CDI annotation with "sensible" default values or specify them in
> >>> > > > > web.xml (http://web.xml)?
> >>> > > >
> >>> > > >
> >>> > > > i dislike xml configuration files, so i would vote for an
> >>> > > > Annotation. but thats personal preference
> >>> > > >
> >>> > > >
> >>> > > > > cheers,
> >>> > > > > /Dan
> >>> > > > >
> >>> > > > >
> >>> > > > > _______________________________________________
> >>> > > > > aerogear-dev mailing list
> >>> > > > > aerogear-dev@lists.jboss.org
> >>> > > > > (mailto:aerogear-dev@lists.jboss.org)
> >>> > > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>> > > >
> >>> > > >
> >>> > > >
> >>> > > > _______________________________________________
> >>> > > > aerogear-dev mailing list
> >>> > > > aerogear-dev@lists.jboss.org (mailto:aerogear-dev@lists.jboss.org)
> >>> > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>> > >
> >>> >
> >>> >
> >>> > _______________________________________________
> >>> > aerogear-dev mailing list
> >>> > aerogear-dev@lists.jboss.org (mailto:aerogear-dev@lists.jboss.org)
> >>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> aerogear-dev mailing list
> >>> aerogear-dev@lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>
> >>
> >>
> >> _______________________________________________
> >> aerogear-dev mailing list
> >> aerogear-dev@lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>
> >
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

-- qmx


_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev