Re: Determining when to port functionality
@John: I think your HTTP filter example is a perfect usecase for
Deactivatable. In most environments the filter will be automatically picked
up because of web-fragment.xml. But if you want to allow users to disable
whatever the filter is for, you can let it implement Deactivateable and add
some manual checks to your code that will only call chain.doFilter() if the
user deactivates the class. So this would allow to disable the filter
functionality although it is auto-registered by the container.
2013/6/2 Mark Struberg
> Deactivatable is only needed for stuff which is active by default.
> In EE-6 a lot such 'auto-pickup' stuff got added, but there was no way to
> get rid of this functionality later. This is what Deactivatable is meant
> for.
>
>
> LieGrue,
> strub
>
>
>
> - Original Message -
> > From: John D. Ament
> > To: dev@deltaspike.apache.org
> > Cc:
> > Sent: Sunday, 2 June 2013, 20:16
> > Subject: Re: Determining when to port functionality
> >
> > Christian,
> >
> > The point is more around how it should work with certain components. For
> > example, let's say you are creating a servlet filter to do something,
> e.g.
> > fire an event on a new HTTP request. You don't annotate it with servlet
> > 3.0 annotations, you do include a web-fragment.xml that maps it, and also
> > give instructions on how to enable it via web.xml (in case the JAR isn't
> in
> > the WAR). However this filter is also activatable. User manually maps
> it
> > via web.xml AND deactivates it. What should happen?
> >
> > John
> >
> >
> > On Sun, Jun 2, 2013 at 1:35 PM, Christian Kaltepoth
> > wrote:
> >
> >> Just a small note regarding Deactivatable. AFAIK you can use it for any
> >> class by manually implementing checks like this:
> >>
> >> if( ClassDeactivationUtils.isActivated( this.getClass() ) ) {
> >>// do whatever the class is responsible for
> >> }
> >>
> >>
> >>
> >>
> >> 2013/6/2 John D. Ament
> >>
> >> > Mark,
> >> >
> >> > I think Deactivatable only works if you're using some kind of CDI
> >> extension
> >> > (e.g. check whether or not the extension should install or not). For
> >> > something like bean val, you need to replace the constraint validator
> >> > factory w/ a custom CDI enabled one; so it becomes simply configuring
> >> > validator to point to a custom one. So while Deactivatable is
> >> preferred, I
> >> > don't think we can require it being used in all cases.
> >> >
> >> > John
> >> >
> >> >
> >> > On Sun, Jun 2, 2013 at 11:06 AM, Mark Struberg
> >
> >> wrote:
> >> >
> >> > > For deactivating features we have the Deactivatable interface +
> > config.
> >> > >
> >> > >
> >> > > LieGrue,
> >> > > strub
> >> > >
> >> > >
> >> > >
> >> > >
> >> > > - Original Message -
> >> > > > From: John D. Ament
> >> > > > To: dev@deltaspike.apache.org
> >> > > > Cc:
> >> > > > Sent: Sunday, 2 June 2013, 17:02
> >> > > > Subject: Determining when to port functionality
> >> > > >
> >> > > > All
> >> > > >
> >> > > > Based on the bean validation thread, I figured I'd start
> > this one off
> >> > so
> >> > > we
> >> > > > can determine when it makes sense to port functionality
> > included in
> >> > later
> >> > > > EE specs to be added to DeltaSpike.
> >> > > >
> >> > > > For one, I think we should only consider this when it's
> > functionality
> >> > > that
> >> > > > has been added to a spec, not for functionality that might
> > be added
> >> to
> >> > a
> >> > > > spec. I also think that it must be a must have that this
> >> functionality
> >> > > be
> >> > > > optional - whether it's a separate module or requires
> > activation; so
> >> > that
> >> > > > if someone is using the new spec they don't get burdened
> > with the DS
> >> > > > implementation being in the middle.
> >> > > >
> >> > > > Second, I think we need to consider whether CODI or Seam3
> > provided
> >> this
> >> > > > functionality. Ultimately we want to get people off of
> > these stacks
> >> > and
> >> > > on
> >> > > > to DeltaSpike, It's easier to drop in a replacement
> > library than it
> >> is
> >> > to
> >> > > > drop in a replacement EE spec.
> >> > > >
> >> > > > Third, we need to look at the complexity to implement. Is
> > it easy or
> >> > is
> >> > > it
> >> > > > hard to do?
> >> > > >
> >> > > > Fourth that I can think of is how strong of a use case is
> > it. Is
> >> this
> >> > > some
> >> > > > brand new programming model that will look odd to someone
> > seeing it
> >> for
> >> > > the
> >> > > > first time? Is it simply some extra methods that can be
> > used?
> >> > > >
> >> > > > Let's build out this list.
> >> > > >
> >> > > > John
> >> > > >
> >> > >
> >> >
> >>
> >>
> >>
> >> --
> >> Christian Kaltepoth
> >> Blog: http://blog.kaltepoth.de/
> >> Twitter: http://twitter.com/chkal
> >> GitHub: https://github.com/chkal
> >>
> >
>
--
Christian Kaltepoth
Blog: http://blog.kaltepoth.de/
Twitter: http:
Re: Jsf page and config?
Basically i thought allowing to switch basepath but you are right se already have sthg customizable and usable Le 2 juin 2013 22:56, "Gerhard Petracek" a écrit : > hi romain, > > so far users were very happy with @View#basePath, @View#name and > @View#extension. > the only request we saw was about a simple mechanism to change the default > naming-conventions. > > with deltaspike that's possible. just use > > org.apache.deltaspike.jsf.api.config.view.View$DefaultBasePathBuilder > and/or > org.apache.deltaspike.jsf.api.config.view.View$DefaultFileNameBuilder > and/or > org.apache.deltaspike.jsf.api.config.view.View$DefaultExtensionBuilder > > to configure your own implementation/s. > > (if it makes sense, we can provide multiple implementations and users just > configure whatever they need.) > > regards, > gerhard > > > > 2013/6/2 Romain Manni-Bucau > > > Hi > > > > We support a nice jsf navigation (strong typed) but i wonder if we > shouldnt > > look in our config (config resolver) if the page name is not overrided. > It > > would allow to use templates easily. > > > > Wdyt? > > > > If we do it we need to orefix the properties as for global alternatives. > > >
Re: Jsf page and config?
hi romain, so far users were very happy with @View#basePath, @View#name and @View#extension. the only request we saw was about a simple mechanism to change the default naming-conventions. with deltaspike that's possible. just use org.apache.deltaspike.jsf.api.config.view.View$DefaultBasePathBuilder and/or org.apache.deltaspike.jsf.api.config.view.View$DefaultFileNameBuilder and/or org.apache.deltaspike.jsf.api.config.view.View$DefaultExtensionBuilder to configure your own implementation/s. (if it makes sense, we can provide multiple implementations and users just configure whatever they need.) regards, gerhard 2013/6/2 Romain Manni-Bucau > Hi > > We support a nice jsf navigation (strong typed) but i wonder if we shouldnt > look in our config (config resolver) if the page name is not overrided. It > would allow to use templates easily. > > Wdyt? > > If we do it we need to orefix the properties as for global alternatives. >
Re: Determining when to port functionality
Deactivatable is only needed for stuff which is active by default.
In EE-6 a lot such 'auto-pickup' stuff got added, but there was no way to get
rid of this functionality later. This is what Deactivatable is meant for.
LieGrue,
strub
- Original Message -
> From: John D. Ament
> To: dev@deltaspike.apache.org
> Cc:
> Sent: Sunday, 2 June 2013, 20:16
> Subject: Re: Determining when to port functionality
>
> Christian,
>
> The point is more around how it should work with certain components. For
> example, let's say you are creating a servlet filter to do something, e.g.
> fire an event on a new HTTP request. You don't annotate it with servlet
> 3.0 annotations, you do include a web-fragment.xml that maps it, and also
> give instructions on how to enable it via web.xml (in case the JAR isn't in
> the WAR). However this filter is also activatable. User manually maps it
> via web.xml AND deactivates it. What should happen?
>
> John
>
>
> On Sun, Jun 2, 2013 at 1:35 PM, Christian Kaltepoth
> wrote:
>
>> Just a small note regarding Deactivatable. AFAIK you can use it for any
>> class by manually implementing checks like this:
>>
>> if( ClassDeactivationUtils.isActivated( this.getClass() ) ) {
>> // do whatever the class is responsible for
>> }
>>
>>
>>
>>
>> 2013/6/2 John D. Ament
>>
>> > Mark,
>> >
>> > I think Deactivatable only works if you're using some kind of CDI
>> extension
>> > (e.g. check whether or not the extension should install or not). For
>> > something like bean val, you need to replace the constraint validator
>> > factory w/ a custom CDI enabled one; so it becomes simply configuring
>> > validator to point to a custom one. So while Deactivatable is
>> preferred, I
>> > don't think we can require it being used in all cases.
>> >
>> > John
>> >
>> >
>> > On Sun, Jun 2, 2013 at 11:06 AM, Mark Struberg
>
>> wrote:
>> >
>> > > For deactivating features we have the Deactivatable interface +
> config.
>> > >
>> > >
>> > > LieGrue,
>> > > strub
>> > >
>> > >
>> > >
>> > >
>> > > - Original Message -
>> > > > From: John D. Ament
>> > > > To: dev@deltaspike.apache.org
>> > > > Cc:
>> > > > Sent: Sunday, 2 June 2013, 17:02
>> > > > Subject: Determining when to port functionality
>> > > >
>> > > > All
>> > > >
>> > > > Based on the bean validation thread, I figured I'd start
> this one off
>> > so
>> > > we
>> > > > can determine when it makes sense to port functionality
> included in
>> > later
>> > > > EE specs to be added to DeltaSpike.
>> > > >
>> > > > For one, I think we should only consider this when it's
> functionality
>> > > that
>> > > > has been added to a spec, not for functionality that might
> be added
>> to
>> > a
>> > > > spec. I also think that it must be a must have that this
>> functionality
>> > > be
>> > > > optional - whether it's a separate module or requires
> activation; so
>> > that
>> > > > if someone is using the new spec they don't get burdened
> with the DS
>> > > > implementation being in the middle.
>> > > >
>> > > > Second, I think we need to consider whether CODI or Seam3
> provided
>> this
>> > > > functionality. Ultimately we want to get people off of
> these stacks
>> > and
>> > > on
>> > > > to DeltaSpike, It's easier to drop in a replacement
> library than it
>> is
>> > to
>> > > > drop in a replacement EE spec.
>> > > >
>> > > > Third, we need to look at the complexity to implement. Is
> it easy or
>> > is
>> > > it
>> > > > hard to do?
>> > > >
>> > > > Fourth that I can think of is how strong of a use case is
> it. Is
>> this
>> > > some
>> > > > brand new programming model that will look odd to someone
> seeing it
>> for
>> > > the
>> > > > first time? Is it simply some extra methods that can be
> used?
>> > > >
>> > > > Let's build out this list.
>> > > >
>> > > > John
>> > > >
>> > >
>> >
>>
>>
>>
>> --
>> Christian Kaltepoth
>> Blog: http://blog.kaltepoth.de/
>> Twitter: http://twitter.com/chkal
>> GitHub: https://github.com/chkal
>>
>
Re: Determining when to port functionality
Christian,
The point is more around how it should work with certain components. For
example, let's say you are creating a servlet filter to do something, e.g.
fire an event on a new HTTP request. You don't annotate it with servlet
3.0 annotations, you do include a web-fragment.xml that maps it, and also
give instructions on how to enable it via web.xml (in case the JAR isn't in
the WAR). However this filter is also activatable. User manually maps it
via web.xml AND deactivates it. What should happen?
John
On Sun, Jun 2, 2013 at 1:35 PM, Christian Kaltepoth
wrote:
> Just a small note regarding Deactivatable. AFAIK you can use it for any
> class by manually implementing checks like this:
>
> if( ClassDeactivationUtils.isActivated( this.getClass() ) ) {
> // do whatever the class is responsible for
> }
>
>
>
>
> 2013/6/2 John D. Ament
>
> > Mark,
> >
> > I think Deactivatable only works if you're using some kind of CDI
> extension
> > (e.g. check whether or not the extension should install or not). For
> > something like bean val, you need to replace the constraint validator
> > factory w/ a custom CDI enabled one; so it becomes simply configuring
> > validator to point to a custom one. So while Deactivatable is
> preferred, I
> > don't think we can require it being used in all cases.
> >
> > John
> >
> >
> > On Sun, Jun 2, 2013 at 11:06 AM, Mark Struberg
> wrote:
> >
> > > For deactivating features we have the Deactivatable interface + config.
> > >
> > >
> > > LieGrue,
> > > strub
> > >
> > >
> > >
> > >
> > > - Original Message -
> > > > From: John D. Ament
> > > > To: dev@deltaspike.apache.org
> > > > Cc:
> > > > Sent: Sunday, 2 June 2013, 17:02
> > > > Subject: Determining when to port functionality
> > > >
> > > > All
> > > >
> > > > Based on the bean validation thread, I figured I'd start this one off
> > so
> > > we
> > > > can determine when it makes sense to port functionality included in
> > later
> > > > EE specs to be added to DeltaSpike.
> > > >
> > > > For one, I think we should only consider this when it's functionality
> > > that
> > > > has been added to a spec, not for functionality that might be added
> to
> > a
> > > > spec. I also think that it must be a must have that this
> functionality
> > > be
> > > > optional - whether it's a separate module or requires activation; so
> > that
> > > > if someone is using the new spec they don't get burdened with the DS
> > > > implementation being in the middle.
> > > >
> > > > Second, I think we need to consider whether CODI or Seam3 provided
> this
> > > > functionality. Ultimately we want to get people off of these stacks
> > and
> > > on
> > > > to DeltaSpike, It's easier to drop in a replacement library than it
> is
> > to
> > > > drop in a replacement EE spec.
> > > >
> > > > Third, we need to look at the complexity to implement. Is it easy or
> > is
> > > it
> > > > hard to do?
> > > >
> > > > Fourth that I can think of is how strong of a use case is it. Is
> this
> > > some
> > > > brand new programming model that will look odd to someone seeing it
> for
> > > the
> > > > first time? Is it simply some extra methods that can be used?
> > > >
> > > > Let's build out this list.
> > > >
> > > > John
> > > >
> > >
> >
>
>
>
> --
> Christian Kaltepoth
> Blog: http://blog.kaltepoth.de/
> Twitter: http://twitter.com/chkal
> GitHub: https://github.com/chkal
>
Re: Determining when to port functionality
Just a small note regarding Deactivatable. AFAIK you can use it for any
class by manually implementing checks like this:
if( ClassDeactivationUtils.isActivated( this.getClass() ) ) {
// do whatever the class is responsible for
}
2013/6/2 John D. Ament
> Mark,
>
> I think Deactivatable only works if you're using some kind of CDI extension
> (e.g. check whether or not the extension should install or not). For
> something like bean val, you need to replace the constraint validator
> factory w/ a custom CDI enabled one; so it becomes simply configuring
> validator to point to a custom one. So while Deactivatable is preferred, I
> don't think we can require it being used in all cases.
>
> John
>
>
> On Sun, Jun 2, 2013 at 11:06 AM, Mark Struberg wrote:
>
> > For deactivating features we have the Deactivatable interface + config.
> >
> >
> > LieGrue,
> > strub
> >
> >
> >
> >
> > - Original Message -
> > > From: John D. Ament
> > > To: dev@deltaspike.apache.org
> > > Cc:
> > > Sent: Sunday, 2 June 2013, 17:02
> > > Subject: Determining when to port functionality
> > >
> > > All
> > >
> > > Based on the bean validation thread, I figured I'd start this one off
> so
> > we
> > > can determine when it makes sense to port functionality included in
> later
> > > EE specs to be added to DeltaSpike.
> > >
> > > For one, I think we should only consider this when it's functionality
> > that
> > > has been added to a spec, not for functionality that might be added to
> a
> > > spec. I also think that it must be a must have that this functionality
> > be
> > > optional - whether it's a separate module or requires activation; so
> that
> > > if someone is using the new spec they don't get burdened with the DS
> > > implementation being in the middle.
> > >
> > > Second, I think we need to consider whether CODI or Seam3 provided this
> > > functionality. Ultimately we want to get people off of these stacks
> and
> > on
> > > to DeltaSpike, It's easier to drop in a replacement library than it is
> to
> > > drop in a replacement EE spec.
> > >
> > > Third, we need to look at the complexity to implement. Is it easy or
> is
> > it
> > > hard to do?
> > >
> > > Fourth that I can think of is how strong of a use case is it. Is this
> > some
> > > brand new programming model that will look odd to someone seeing it for
> > the
> > > first time? Is it simply some extra methods that can be used?
> > >
> > > Let's build out this list.
> > >
> > > John
> > >
> >
>
--
Christian Kaltepoth
Blog: http://blog.kaltepoth.de/
Twitter: http://twitter.com/chkal
GitHub: https://github.com/chkal
Re: DISCUSS DeltaSpike-332
hi john, i don't agree with everything you wrote, but that isn't important for now. you should test all your applications in any case (esp. with the approach used by the bv-module of seam3). furthermore, it isn't the only alternative you have. once you show users the possible alternatives, a lot of them prefer e.g. BeanProvider.injectFields(this) in ConstraintValidator#initialize, because it's simple enough and they just have 1-3 constraint-validators which need it at all (and you don't need an additional dependency for it). anyway, imo it doesn't make sense to continue the discussion without an agreed deprecation-strategy. regards, gerhard 2013/6/2 John D. Ament > Gerhard, > > It's not feasible to test a server upgrade ourselves. It's not about > checking whether or not the server accepts it, but that all of the > applications on the server accept it. Let's say you're running a weblogic > instance that has 4 different apps on it. Each of those 4 apps needs to be > regression tested to ensure that the upgrade of the library doesn't impact > any functionality. > > This is easy to do if you have automated testing, but not many people > actually have this setup in a way to run to cover high enough to verify > there are no issues. > > John > > > On Sun, Jun 2, 2013 at 8:07 AM, Gerhard Petracek < > gerhard.petra...@gmail.com > > wrote: > > > @ mark: > > you aren't allowed to replace such libs manually (in the server itself), > > but e.g. in wls you have an own config-mechanism to do exactly that (per > > application). > > before we just add a whole module for it, we should test such upgrades > with > > the servers in question. > > upgrading other libs like jsf is done frequently (without issues). > > > > @ john: > > i've talked with a lot of people about this topic (since 2011 -> way > before > > bv 1.1). > > (most) conservative teams wouldn't even add an additional dependency to > get > > rid of 3-4 lines (per application). > > others will keep codi or whatever they have until ee7, since there is no > > issue with doing that. > > > > i would also question our ViewScopedContext (not only due to jsf 2.2). > > however, we don't have a whole module for it and there aren't that many > > alternatives (like with bv) -> i'm fine with keeping it (for now). > > > > regards, > > gerhard > > > > > > > > 2013/6/2 Romain Manni-Bucau > > > > > Hmm, thinking of it we should consider how hard it is to dev and > maintain > > > and if it is the same code as the new version of the lib. If so thats > not > > > relevant IMO, if easy and small enough it could be added IMHO > > > Le 2 juin 2013 13:08, "John D. Ament" a > écrit : > > > > > > > Definitely. When you're a consultant, you typically don't tell what > > > 3PL's > > > > you're using (just dealt with this recently, found some GPL in our > > > > product... not fun). Adding in a 3PL that is apache licensed is > > > typically > > > > ok. Upgrading a core app server lib without real reason for it is a > > > pain. > > > > Right now, I think JBoss ans TomEE do it quite easily but the big > boys > > > > (WebLogic & WebSphere) it's still a bit of a pain. Sometimes your > app > > is > > > > running on shared binaries, so then both apps need to be updated and > > you > > > > can't embed the library update for whatever class loading problem > comes > > > up. > > > > > > > > Anyways, thanks Mark & Jason for support on this. > > > > > > > > I agree w/ Gerhard, we need a general strategy for introducing stuff > > > added > > > > by later EE specs. It seems like we're inconsistent WRT this topic; > > e.g. > > > > JSF features were added, Servlet features are getting added, but JMS > > and > > > > BeanVal seemed to cause disdain in the group (not sure if it's who > > > proposed > > > > it or the lack of use of these specs). > > > > > > > > John > > > > > > > > > > > > On Sun, Jun 2, 2013 at 5:03 AM, Romain Manni-Bucau < > > > rmannibu...@gmail.com > > > > >wrote: > > > > > > > > > Weird if that s true but in such a case app will be constrained > too i > > > > think > > > > > Le 2 juin 2013 10:25, "Mark Struberg" a écrit > : > > > > > > > > > > > > > > > > > > > > > > > Pretty often you are not even allowed to change those libs for > > > > > production. > > > > > > Sometimes because of legal constructs (ever looked at the Oracle > > > > license > > > > > > for WebLogic?) and sometimes because of company reasons. > > > > > > > > > > > > Thus I'm +1 for adding it as _optional_ feature. > > > > > > > > > > > > LieGrue, > > > > > > strub > > > > > > > > > > > > > > > > > > > > > > > > > > From: Romain Manni-Bucau > > > > > > >To: dev@deltaspike.apache.org > > > > > > >Sent: Sunday, 2 June 2013, 8:57 > > > > > > >Subject: Re: DISCUSS DeltaSpike-332 > > > > > > > > > > > > > > > > > > > > >As said before, if using the javaee7 lib is easy in javaee6 no > > need > > > of > > > > > any > > > > > > >glue. That should be the case for bval, jpa... > >
Re: Determining when to port functionality
Mark, I think Deactivatable only works if you're using some kind of CDI extension (e.g. check whether or not the extension should install or not). For something like bean val, you need to replace the constraint validator factory w/ a custom CDI enabled one; so it becomes simply configuring validator to point to a custom one. So while Deactivatable is preferred, I don't think we can require it being used in all cases. John On Sun, Jun 2, 2013 at 11:06 AM, Mark Struberg wrote: > For deactivating features we have the Deactivatable interface + config. > > > LieGrue, > strub > > > > > - Original Message - > > From: John D. Ament > > To: dev@deltaspike.apache.org > > Cc: > > Sent: Sunday, 2 June 2013, 17:02 > > Subject: Determining when to port functionality > > > > All > > > > Based on the bean validation thread, I figured I'd start this one off so > we > > can determine when it makes sense to port functionality included in later > > EE specs to be added to DeltaSpike. > > > > For one, I think we should only consider this when it's functionality > that > > has been added to a spec, not for functionality that might be added to a > > spec. I also think that it must be a must have that this functionality > be > > optional - whether it's a separate module or requires activation; so that > > if someone is using the new spec they don't get burdened with the DS > > implementation being in the middle. > > > > Second, I think we need to consider whether CODI or Seam3 provided this > > functionality. Ultimately we want to get people off of these stacks and > on > > to DeltaSpike, It's easier to drop in a replacement library than it is to > > drop in a replacement EE spec. > > > > Third, we need to look at the complexity to implement. Is it easy or is > it > > hard to do? > > > > Fourth that I can think of is how strong of a use case is it. Is this > some > > brand new programming model that will look odd to someone seeing it for > the > > first time? Is it simply some extra methods that can be used? > > > > Let's build out this list. > > > > John > > >
Re: Determining when to port functionality
For deactivating features we have the Deactivatable interface + config. LieGrue, strub - Original Message - > From: John D. Ament > To: dev@deltaspike.apache.org > Cc: > Sent: Sunday, 2 June 2013, 17:02 > Subject: Determining when to port functionality > > All > > Based on the bean validation thread, I figured I'd start this one off so we > can determine when it makes sense to port functionality included in later > EE specs to be added to DeltaSpike. > > For one, I think we should only consider this when it's functionality that > has been added to a spec, not for functionality that might be added to a > spec. I also think that it must be a must have that this functionality be > optional - whether it's a separate module or requires activation; so that > if someone is using the new spec they don't get burdened with the DS > implementation being in the middle. > > Second, I think we need to consider whether CODI or Seam3 provided this > functionality. Ultimately we want to get people off of these stacks and on > to DeltaSpike, It's easier to drop in a replacement library than it is to > drop in a replacement EE spec. > > Third, we need to look at the complexity to implement. Is it easy or is it > hard to do? > > Fourth that I can think of is how strong of a use case is it. Is this some > brand new programming model that will look odd to someone seeing it for the > first time? Is it simply some extra methods that can be used? > > Let's build out this list. > > John >
Determining when to port functionality
All Based on the bean validation thread, I figured I'd start this one off so we can determine when it makes sense to port functionality included in later EE specs to be added to DeltaSpike. For one, I think we should only consider this when it's functionality that has been added to a spec, not for functionality that might be added to a spec. I also think that it must be a must have that this functionality be optional - whether it's a separate module or requires activation; so that if someone is using the new spec they don't get burdened with the DS implementation being in the middle. Second, I think we need to consider whether CODI or Seam3 provided this functionality. Ultimately we want to get people off of these stacks and on to DeltaSpike, It's easier to drop in a replacement library than it is to drop in a replacement EE spec. Third, we need to look at the complexity to implement. Is it easy or is it hard to do? Fourth that I can think of is how strong of a use case is it. Is this some brand new programming model that will look odd to someone seeing it for the first time? Is it simply some extra methods that can be used? Let's build out this list. John
Re: DISCUSS DeltaSpike-332
Gerhard, It's not feasible to test a server upgrade ourselves. It's not about checking whether or not the server accepts it, but that all of the applications on the server accept it. Let's say you're running a weblogic instance that has 4 different apps on it. Each of those 4 apps needs to be regression tested to ensure that the upgrade of the library doesn't impact any functionality. This is easy to do if you have automated testing, but not many people actually have this setup in a way to run to cover high enough to verify there are no issues. John On Sun, Jun 2, 2013 at 8:07 AM, Gerhard Petracek wrote: > @ mark: > you aren't allowed to replace such libs manually (in the server itself), > but e.g. in wls you have an own config-mechanism to do exactly that (per > application). > before we just add a whole module for it, we should test such upgrades with > the servers in question. > upgrading other libs like jsf is done frequently (without issues). > > @ john: > i've talked with a lot of people about this topic (since 2011 -> way before > bv 1.1). > (most) conservative teams wouldn't even add an additional dependency to get > rid of 3-4 lines (per application). > others will keep codi or whatever they have until ee7, since there is no > issue with doing that. > > i would also question our ViewScopedContext (not only due to jsf 2.2). > however, we don't have a whole module for it and there aren't that many > alternatives (like with bv) -> i'm fine with keeping it (for now). > > regards, > gerhard > > > > 2013/6/2 Romain Manni-Bucau > > > Hmm, thinking of it we should consider how hard it is to dev and maintain > > and if it is the same code as the new version of the lib. If so thats not > > relevant IMO, if easy and small enough it could be added IMHO > > Le 2 juin 2013 13:08, "John D. Ament" a écrit : > > > > > Definitely. When you're a consultant, you typically don't tell what > > 3PL's > > > you're using (just dealt with this recently, found some GPL in our > > > product... not fun). Adding in a 3PL that is apache licensed is > > typically > > > ok. Upgrading a core app server lib without real reason for it is a > > pain. > > > Right now, I think JBoss ans TomEE do it quite easily but the big boys > > > (WebLogic & WebSphere) it's still a bit of a pain. Sometimes your app > is > > > running on shared binaries, so then both apps need to be updated and > you > > > can't embed the library update for whatever class loading problem comes > > up. > > > > > > Anyways, thanks Mark & Jason for support on this. > > > > > > I agree w/ Gerhard, we need a general strategy for introducing stuff > > added > > > by later EE specs. It seems like we're inconsistent WRT this topic; > e.g. > > > JSF features were added, Servlet features are getting added, but JMS > and > > > BeanVal seemed to cause disdain in the group (not sure if it's who > > proposed > > > it or the lack of use of these specs). > > > > > > John > > > > > > > > > On Sun, Jun 2, 2013 at 5:03 AM, Romain Manni-Bucau < > > rmannibu...@gmail.com > > > >wrote: > > > > > > > Weird if that s true but in such a case app will be constrained too i > > > think > > > > Le 2 juin 2013 10:25, "Mark Struberg" a écrit : > > > > > > > > > > > > > > > > > > > Pretty often you are not even allowed to change those libs for > > > > production. > > > > > Sometimes because of legal constructs (ever looked at the Oracle > > > license > > > > > for WebLogic?) and sometimes because of company reasons. > > > > > > > > > > Thus I'm +1 for adding it as _optional_ feature. > > > > > > > > > > LieGrue, > > > > > strub > > > > > > > > > > > > > > > > > > > > > > From: Romain Manni-Bucau > > > > > >To: dev@deltaspike.apache.org > > > > > >Sent: Sunday, 2 June 2013, 8:57 > > > > > >Subject: Re: DISCUSS DeltaSpike-332 > > > > > > > > > > > > > > > > > >As said before, if using the javaee7 lib is easy in javaee6 no > need > > of > > > > any > > > > > >glue. That should be the case for bval, jpa... > > > > > >Le 2 juin 2013 03:26, "Jason Porter" a > > > écrit > > > > : > > > > > > > > > > > >> FWIW I'm +1 for the BeanVal stuff and keeping it disabled by > > > default. > > > > > Just > > > > > >> because Java EE 7 is soon to be released doesn't mean that > people > > > will > > > > > >> migrate to it over night, as has already been said. I'm sure > there > > > are > > > > > >> quite a few large corporations still on Java EE 5 and probably > > will > > > be > > > > > for > > > > > >> a while. > > > > > >> > > > > > >> > > > > > >> If the coding is minimal to bring some Java EE 7 features to > Java > > > EE 6 > > > > > >> via DeltaSpike, I don't see a reason not to do this. > > > > > >> > > > > > >> — > > > > > >> Sent from Mailbox for iPhone > > > > > >> > > > > > >> On Sat, Jun 1, 2013 at 1:55 PM, Gerhard Petracek > > > > > >> wrote: > > > > > >> > > > > > >> > hi thomas, > > > > > >> > no - we don't have @Advanced. > > > > > >> > (-1 for ad
Re: DISCUSS DeltaSpike-332
@ mark: you aren't allowed to replace such libs manually (in the server itself), but e.g. in wls you have an own config-mechanism to do exactly that (per application). before we just add a whole module for it, we should test such upgrades with the servers in question. upgrading other libs like jsf is done frequently (without issues). @ john: i've talked with a lot of people about this topic (since 2011 -> way before bv 1.1). (most) conservative teams wouldn't even add an additional dependency to get rid of 3-4 lines (per application). others will keep codi or whatever they have until ee7, since there is no issue with doing that. i would also question our ViewScopedContext (not only due to jsf 2.2). however, we don't have a whole module for it and there aren't that many alternatives (like with bv) -> i'm fine with keeping it (for now). regards, gerhard 2013/6/2 Romain Manni-Bucau > Hmm, thinking of it we should consider how hard it is to dev and maintain > and if it is the same code as the new version of the lib. If so thats not > relevant IMO, if easy and small enough it could be added IMHO > Le 2 juin 2013 13:08, "John D. Ament" a écrit : > > > Definitely. When you're a consultant, you typically don't tell what > 3PL's > > you're using (just dealt with this recently, found some GPL in our > > product... not fun). Adding in a 3PL that is apache licensed is > typically > > ok. Upgrading a core app server lib without real reason for it is a > pain. > > Right now, I think JBoss ans TomEE do it quite easily but the big boys > > (WebLogic & WebSphere) it's still a bit of a pain. Sometimes your app is > > running on shared binaries, so then both apps need to be updated and you > > can't embed the library update for whatever class loading problem comes > up. > > > > Anyways, thanks Mark & Jason for support on this. > > > > I agree w/ Gerhard, we need a general strategy for introducing stuff > added > > by later EE specs. It seems like we're inconsistent WRT this topic; e.g. > > JSF features were added, Servlet features are getting added, but JMS and > > BeanVal seemed to cause disdain in the group (not sure if it's who > proposed > > it or the lack of use of these specs). > > > > John > > > > > > On Sun, Jun 2, 2013 at 5:03 AM, Romain Manni-Bucau < > rmannibu...@gmail.com > > >wrote: > > > > > Weird if that s true but in such a case app will be constrained too i > > think > > > Le 2 juin 2013 10:25, "Mark Struberg" a écrit : > > > > > > > > > > > > > > > Pretty often you are not even allowed to change those libs for > > > production. > > > > Sometimes because of legal constructs (ever looked at the Oracle > > license > > > > for WebLogic?) and sometimes because of company reasons. > > > > > > > > Thus I'm +1 for adding it as _optional_ feature. > > > > > > > > LieGrue, > > > > strub > > > > > > > > > > > > > > > > > > From: Romain Manni-Bucau > > > > >To: dev@deltaspike.apache.org > > > > >Sent: Sunday, 2 June 2013, 8:57 > > > > >Subject: Re: DISCUSS DeltaSpike-332 > > > > > > > > > > > > > > >As said before, if using the javaee7 lib is easy in javaee6 no need > of > > > any > > > > >glue. That should be the case for bval, jpa... > > > > >Le 2 juin 2013 03:26, "Jason Porter" a > > écrit > > > : > > > > > > > > > >> FWIW I'm +1 for the BeanVal stuff and keeping it disabled by > > default. > > > > Just > > > > >> because Java EE 7 is soon to be released doesn't mean that people > > will > > > > >> migrate to it over night, as has already been said. I'm sure there > > are > > > > >> quite a few large corporations still on Java EE 5 and probably > will > > be > > > > for > > > > >> a while. > > > > >> > > > > >> > > > > >> If the coding is minimal to bring some Java EE 7 features to Java > > EE 6 > > > > >> via DeltaSpike, I don't see a reason not to do this. > > > > >> > > > > >> — > > > > >> Sent from Mailbox for iPhone > > > > >> > > > > >> On Sat, Jun 1, 2013 at 1:55 PM, Gerhard Petracek > > > > >> wrote: > > > > >> > > > > >> > hi thomas, > > > > >> > no - we don't have @Advanced. > > > > >> > (-1 for adding it and therefore -1 for adding parts which would > > need > > > > >> such a > > > > >> > qualifier.) > > > > >> > regards, > > > > >> > gerhard > > > > >> > 2013/6/1 Thomas Andraschko > > > > >> >> Jep, there will be many EE6 users out there the next 1-3 years. > > > > >> >> > > > > >> >> there are also other possible features: > > > > >> >> - injection in other BV artifacts - e.g. MessageInterpolator > > > > >> >> - method validation (if possible with 1.0 specs) > > > > >> >> > > > > >> >> AFAIK all this features will be available in BV 1.1, so it > would > > be > > > > >> enough > > > > >> >> to create a BV1.0 module. > > > > >> >> > > > > >> >> Is there already something available like @Advanded in DS? > > > > >> >> I personally don't like it. Do we really save performance? > > > > >> >> Probably the best solution is to just activate injection if the > >
Re: DISCUSS DeltaSpike-332
Hmm, thinking of it we should consider how hard it is to dev and maintain and if it is the same code as the new version of the lib. If so thats not relevant IMO, if easy and small enough it could be added IMHO Le 2 juin 2013 13:08, "John D. Ament" a écrit : > Definitely. When you're a consultant, you typically don't tell what 3PL's > you're using (just dealt with this recently, found some GPL in our > product... not fun). Adding in a 3PL that is apache licensed is typically > ok. Upgrading a core app server lib without real reason for it is a pain. > Right now, I think JBoss ans TomEE do it quite easily but the big boys > (WebLogic & WebSphere) it's still a bit of a pain. Sometimes your app is > running on shared binaries, so then both apps need to be updated and you > can't embed the library update for whatever class loading problem comes up. > > Anyways, thanks Mark & Jason for support on this. > > I agree w/ Gerhard, we need a general strategy for introducing stuff added > by later EE specs. It seems like we're inconsistent WRT this topic; e.g. > JSF features were added, Servlet features are getting added, but JMS and > BeanVal seemed to cause disdain in the group (not sure if it's who proposed > it or the lack of use of these specs). > > John > > > On Sun, Jun 2, 2013 at 5:03 AM, Romain Manni-Bucau >wrote: > > > Weird if that s true but in such a case app will be constrained too i > think > > Le 2 juin 2013 10:25, "Mark Struberg" a écrit : > > > > > > > > > > > Pretty often you are not even allowed to change those libs for > > production. > > > Sometimes because of legal constructs (ever looked at the Oracle > license > > > for WebLogic?) and sometimes because of company reasons. > > > > > > Thus I'm +1 for adding it as _optional_ feature. > > > > > > LieGrue, > > > strub > > > > > > > > > > > > > > From: Romain Manni-Bucau > > > >To: dev@deltaspike.apache.org > > > >Sent: Sunday, 2 June 2013, 8:57 > > > >Subject: Re: DISCUSS DeltaSpike-332 > > > > > > > > > > > >As said before, if using the javaee7 lib is easy in javaee6 no need of > > any > > > >glue. That should be the case for bval, jpa... > > > >Le 2 juin 2013 03:26, "Jason Porter" a > écrit > > : > > > > > > > >> FWIW I'm +1 for the BeanVal stuff and keeping it disabled by > default. > > > Just > > > >> because Java EE 7 is soon to be released doesn't mean that people > will > > > >> migrate to it over night, as has already been said. I'm sure there > are > > > >> quite a few large corporations still on Java EE 5 and probably will > be > > > for > > > >> a while. > > > >> > > > >> > > > >> If the coding is minimal to bring some Java EE 7 features to Java > EE 6 > > > >> via DeltaSpike, I don't see a reason not to do this. > > > >> > > > >> — > > > >> Sent from Mailbox for iPhone > > > >> > > > >> On Sat, Jun 1, 2013 at 1:55 PM, Gerhard Petracek > > > >> wrote: > > > >> > > > >> > hi thomas, > > > >> > no - we don't have @Advanced. > > > >> > (-1 for adding it and therefore -1 for adding parts which would > need > > > >> such a > > > >> > qualifier.) > > > >> > regards, > > > >> > gerhard > > > >> > 2013/6/1 Thomas Andraschko > > > >> >> Jep, there will be many EE6 users out there the next 1-3 years. > > > >> >> > > > >> >> there are also other possible features: > > > >> >> - injection in other BV artifacts - e.g. MessageInterpolator > > > >> >> - method validation (if possible with 1.0 specs) > > > >> >> > > > >> >> AFAIK all this features will be available in BV 1.1, so it would > be > > > >> enough > > > >> >> to create a BV1.0 module. > > > >> >> > > > >> >> Is there already something available like @Advanded in DS? > > > >> >> I personally don't like it. Do we really save performance? > > > >> >> Probably the best solution is to just activate injection if the > > > module > > > >> is > > > >> >> included. > > > >> >> > > > >> >> > > > >> >> Thats the same with JSF 2.2 ViewScoped. > > > >> >> How will it be handled in DS? > > > >> >> > > > >> >> > > > >> >> 2013/6/1 Mark Struberg > > > >> >> > > > >> >> > As others said, in an EE-6 container you cannot just exchange > the > > > bean > > > >> >> > validation provider easily. > > > >> >> > > > > >> >> > > > > >> >> > Yes, it's already possible to use the BeanProvider to achieve > > this > > > >> goal. > > > >> >> > But it's also nice if that would work out of the box. > > > >> >> > An important criteria is of course that it must also work when > > bean > > > >> >> > validation-1.1 is available which will do the injection itself. > > > >> >> > > > > >> >> > > > > >> >> > Imo it's mostly a question about what else we like to add into > > this > > > >> >> module. > > > >> >> > > > > >> >> > LieGrue, > > > >> >> > strub > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > - Original Message - > > > >> >> > > From: Gerhard Petracek > > > >> >> > > To: dev@deltaspike.apache.org > > > >> >> > > Cc: > > > >> >> > > Sent: Saturday, 1 June 2013,
[jira] [Created] (DELTASPIKE-378) ProjectStage-aware and Property-aware configuration
Mark Struberg created DELTASPIKE-378: Summary: ProjectStage-aware and Property-aware configuration Key: DELTASPIKE-378 URL: https://issues.apache.org/jira/browse/DELTASPIKE-378 Project: DeltaSpike Issue Type: New Feature Components: Configuration Affects Versions: 0.4 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 0.5 In many situations one likes to use different configurations depending on the ProjectStage. E.g. to take the JPA configuration for the local database from a properties file which contains the credentials and JDBC driver class for the local test setup in ProjectStage Development and UnitTest, but use a JNDI provided DataSource for ProjectStage Production. Same goes with using various kind of configuration depending on a configured property like e.g. 'dbvendor'. Using some Oracle specific flags if dbvendor is set to 'oracle' vs other flags for 'mysql'. To not come into chicken/egg issues, I propose that the whole change only affects our ConfigResolver and the producers for @ConfigProperty I suggest to add 2 new methods to ConfigResolver: #getProjectStageAwarePropertyValue(String key) This would basically first do a lookup of key + projectStage, e.g. someKey.Production and if it doesn't find anything, then looks up the configured value without the ProjectStage. #getPropertyAwarePropertyValue(String key, String propertyName); The lookup pack for key= 'someconfig', ProjectStage = Production and propertyName = 'dbvendor' would be: * lookup dbvendor.Production, then if not found do a fallback to dbvendor. Let's say we found the value 'mysql' that way. * lookup someconfig.mysql.Production * fallback: lookup someconfig.mysql * fallback: lookup someconfig.Production * fallback: lookup someconfig -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: DISCUSS DeltaSpike-332
Definitely. When you're a consultant, you typically don't tell what 3PL's you're using (just dealt with this recently, found some GPL in our product... not fun). Adding in a 3PL that is apache licensed is typically ok. Upgrading a core app server lib without real reason for it is a pain. Right now, I think JBoss ans TomEE do it quite easily but the big boys (WebLogic & WebSphere) it's still a bit of a pain. Sometimes your app is running on shared binaries, so then both apps need to be updated and you can't embed the library update for whatever class loading problem comes up. Anyways, thanks Mark & Jason for support on this. I agree w/ Gerhard, we need a general strategy for introducing stuff added by later EE specs. It seems like we're inconsistent WRT this topic; e.g. JSF features were added, Servlet features are getting added, but JMS and BeanVal seemed to cause disdain in the group (not sure if it's who proposed it or the lack of use of these specs). John On Sun, Jun 2, 2013 at 5:03 AM, Romain Manni-Bucau wrote: > Weird if that s true but in such a case app will be constrained too i think > Le 2 juin 2013 10:25, "Mark Struberg" a écrit : > > > > > > > Pretty often you are not even allowed to change those libs for > production. > > Sometimes because of legal constructs (ever looked at the Oracle license > > for WebLogic?) and sometimes because of company reasons. > > > > Thus I'm +1 for adding it as _optional_ feature. > > > > LieGrue, > > strub > > > > > > > > > > From: Romain Manni-Bucau > > >To: dev@deltaspike.apache.org > > >Sent: Sunday, 2 June 2013, 8:57 > > >Subject: Re: DISCUSS DeltaSpike-332 > > > > > > > > >As said before, if using the javaee7 lib is easy in javaee6 no need of > any > > >glue. That should be the case for bval, jpa... > > >Le 2 juin 2013 03:26, "Jason Porter" a écrit > : > > > > > >> FWIW I'm +1 for the BeanVal stuff and keeping it disabled by default. > > Just > > >> because Java EE 7 is soon to be released doesn't mean that people will > > >> migrate to it over night, as has already been said. I'm sure there are > > >> quite a few large corporations still on Java EE 5 and probably will be > > for > > >> a while. > > >> > > >> > > >> If the coding is minimal to bring some Java EE 7 features to Java EE 6 > > >> via DeltaSpike, I don't see a reason not to do this. > > >> > > >> — > > >> Sent from Mailbox for iPhone > > >> > > >> On Sat, Jun 1, 2013 at 1:55 PM, Gerhard Petracek > > >> wrote: > > >> > > >> > hi thomas, > > >> > no - we don't have @Advanced. > > >> > (-1 for adding it and therefore -1 for adding parts which would need > > >> such a > > >> > qualifier.) > > >> > regards, > > >> > gerhard > > >> > 2013/6/1 Thomas Andraschko > > >> >> Jep, there will be many EE6 users out there the next 1-3 years. > > >> >> > > >> >> there are also other possible features: > > >> >> - injection in other BV artifacts - e.g. MessageInterpolator > > >> >> - method validation (if possible with 1.0 specs) > > >> >> > > >> >> AFAIK all this features will be available in BV 1.1, so it would be > > >> enough > > >> >> to create a BV1.0 module. > > >> >> > > >> >> Is there already something available like @Advanded in DS? > > >> >> I personally don't like it. Do we really save performance? > > >> >> Probably the best solution is to just activate injection if the > > module > > >> is > > >> >> included. > > >> >> > > >> >> > > >> >> Thats the same with JSF 2.2 ViewScoped. > > >> >> How will it be handled in DS? > > >> >> > > >> >> > > >> >> 2013/6/1 Mark Struberg > > >> >> > > >> >> > As others said, in an EE-6 container you cannot just exchange the > > bean > > >> >> > validation provider easily. > > >> >> > > > >> >> > > > >> >> > Yes, it's already possible to use the BeanProvider to achieve > this > > >> goal. > > >> >> > But it's also nice if that would work out of the box. > > >> >> > An important criteria is of course that it must also work when > bean > > >> >> > validation-1.1 is available which will do the injection itself. > > >> >> > > > >> >> > > > >> >> > Imo it's mostly a question about what else we like to add into > this > > >> >> module. > > >> >> > > > >> >> > LieGrue, > > >> >> > strub > > >> >> > > > >> >> > > > >> >> > > > >> >> > - Original Message - > > >> >> > > From: Gerhard Petracek > > >> >> > > To: dev@deltaspike.apache.org > > >> >> > > Cc: > > >> >> > > Sent: Saturday, 1 June 2013, 20:25 > > >> >> > > Subject: Re: DISCUSS DeltaSpike-332 > > >> >> > > > > >> >> > > hi thomas, > > >> >> > > > > >> >> > > yes, because we based everything on the jsf 1.2 api. > > >> >> > > (~nothing from the jsf2+ api was needed to provide what you get > > with > > >> >> > codi.) > > >> >> > > > > >> >> > > @ "...in each validator...": > > >> >> > > projects usually don't have that many constraint-validators > which > > >> need > > >> >> > > other services (and if so they might overuse it). > > >> >> > > > > >> >> > > we should e
[jira] [Assigned] (DELTASPIKE-335) re-visit support of EARs
[ https://issues.apache.org/jira/browse/DELTASPIKE-335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg reassigned DELTASPIKE-335: Assignee: Mark Struberg > re-visit support of EARs > > > Key: DELTASPIKE-335 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-335 > Project: DeltaSpike > Issue Type: Task >Affects Versions: 0.4 >Reporter: Gerhard Petracek >Assignee: Mark Struberg > Fix For: 0.5 > > > #1 > our current approach to get rid of basic classloader issues (esp. with EARs) > is to collect information during bootstrapping and inject the extension > instance to consume the result later on. that can expose the collected > information of one web-app to other web-apps (of the same EAR). in codi we > used the classloader as key, however, this approach also has disadvantages. > (something like @WebApplicationName would only work in some cases.) > #2 > there was no real agreement about https://issues.jboss.org/browse/CDI-129. > currently we expect that @ApplicationScoped is separated per web-app. > however, that's at least not the case with current versions of weld. > -> (at least for current versions of weld) we have to think about an own > @WebApplicationScoped -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (DELTASPIKE-377) Supporting injection of basic servlet objects
Christian Kaltepoth created DELTASPIKE-377: -- Summary: Supporting injection of basic servlet objects Key: DELTASPIKE-377 URL: https://issues.apache.org/jira/browse/DELTASPIKE-377 Project: DeltaSpike Issue Type: New Feature Affects Versions: 0.5 Reporter: Christian Kaltepoth Assignee: Christian Kaltepoth Fix For: 0.5 The servlet module should support injection of the following servlet objects: * ServletRequest / HttpServletRequest * ServletResponse / HttpServletResponse * HttpSession * ServletContext We must use a special qualifier because CDI 1.1 provides this out of the box. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DELTASPIKE-360) alternative LocaleResolver which is aware of supported locales
[ https://issues.apache.org/jira/browse/DELTASPIKE-360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13672458#comment-13672458 ] Mark Struberg commented on DELTASPIKE-360: -- gerhard, would you like to commit it now? > alternative LocaleResolver which is aware of supported locales > -- > > Key: DELTASPIKE-360 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-360 > Project: DeltaSpike > Issue Type: Improvement > Components: JSF-Module >Reporter: Christian Beikov > Fix For: 0.5 > > Attachments: DELTASPIKE-360.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (DELTASPIKE-360) alternative LocaleResolver which is aware of supported locales
[ https://issues.apache.org/jira/browse/DELTASPIKE-360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg reassigned DELTASPIKE-360: Assignee: Gerhard Petracek > alternative LocaleResolver which is aware of supported locales > -- > > Key: DELTASPIKE-360 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-360 > Project: DeltaSpike > Issue Type: Improvement > Components: JSF-Module >Reporter: Christian Beikov >Assignee: Gerhard Petracek > Fix For: 0.5 > > Attachments: DELTASPIKE-360.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (DELTASPIKE-376) Propagation of basic servlet events to the CDI event bus
Christian Kaltepoth created DELTASPIKE-376: -- Summary: Propagation of basic servlet events to the CDI event bus Key: DELTASPIKE-376 URL: https://issues.apache.org/jira/browse/DELTASPIKE-376 Project: DeltaSpike Issue Type: New Feature Affects Versions: 0.5 Reporter: Christian Kaltepoth Assignee: Christian Kaltepoth Fix For: 0.5 The servlet module should send events when the following servlet objects are created and/or destroyed: * HttpServletRequest * HttpServletResponse * HttpSession * ServletContext -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (DELTASPIKE-375) Create servlet module maven structure
Christian Kaltepoth created DELTASPIKE-375: -- Summary: Create servlet module maven structure Key: DELTASPIKE-375 URL: https://issues.apache.org/jira/browse/DELTASPIKE-375 Project: DeltaSpike Issue Type: New Feature Affects Versions: 0.5 Reporter: Christian Kaltepoth Assignee: Christian Kaltepoth Fix For: 0.5 Create the basic structure of the new servlet module. As discussed earlier on the list, it will go to modules/servlet. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Servlet module
Hey John, I'm almost finished with the stuff I wanted to get in for a first version. What I got so far is propagation of servlet events for creation/destruction of request, response, session and servlet context. And also injection of request, response and session. What I'm currently finishing is the injection of the servlet context, which is a bit tricky. I think I'll be able to finish it in 3-4 days and push it out to github so everyone cat give feedback. I'll create a few JIRA issues for the stuff that is already implemented. Feel free to add anything you think that is missing. Christian 2013/6/1 John D. Ament > Hey Christian, > > Just wondering how far you got with this. Since 0.5 is now starting up > maybe we can start entering JIRAs for the features? > > > On Tue, May 14, 2013 at 4:05 AM, Christian Kaltepoth < > christ...@kaltepoth.de > > wrote: > > > Sure, as I already wrote I would start in a separate branch on github and > > merge later after 0.4 is out. > > > > > > 2013/5/14 Mark Struberg > > > > > +1. Could you please start working on it in a branch? > > > I really like to release 0.4 sonish (maybe end of this week?) > > > After that we could go for it in master. > > > > > > LieGrue, > > > strub > > > > > > > > > > > > > > > - Original Message - > > > > From: Jason Porter > > > > To: "deltaspike-...@incubator.apache.org" < > > > deltaspike-...@incubator.apache.org> > > > > Cc: > > > > Sent: Monday, 13 May 2013, 18:35 > > > > Subject: Re: Servlet module > > > > > > > > I see no reason not to. Just keep rebasing (if you're working in a > > > separate > > > > module there shouldn't be any conflicts) until we're able to start > work > > > > on > > > > 0.5. > > > > > > > > > > > > On Mon, May 13, 2013 at 10:16 AM, Romain Manni-Bucau > > > > wrote: > > > > > > > >> Since the module is light +1 > > > >> Le 13 mai 2013 18:11, "John D. Ament" > > > > a écrit : > > > >> > > > >> > +1. This is actually one thing I need to finish porting an app > > from > > > >> seam3 > > > >> > to DS. If you want help doing it let me know. > > > >> > > > > >> > > > > >> > On Mon, May 13, 2013 at 12:03 PM, Christian Kaltepoth < > > > >> > christ...@kaltepoth.de> wrote: > > > >> > > > > >> > > Hey all, > > > >> > > > > > >> > > as I already discussed with Mark and Arne two weeks ago, I'm > > > > really > > > >> > > interested in working on the servlet module for DeltaSpike. > This > > > > topic > > > >> > was > > > >> > > discussed several times on the list (see [1], [2]) and I think > > > > there > > > >> was > > > >> > an > > > >> > > agreement to target this for 0.5. Although 0.4 hasn't been > > > > released > > > >> yet, > > > >> > I > > > >> > > would love to spend some time hacking on this. :) > > > >> > > > > > >> > > In my opinion the most important features for the module would > > > > be: > > > >> > > > > > >> > >- Producers for servlet objects like the HttpServletRequest, > > > >> > >ServletContext, etc. As this will be part of CDI 1.1, the > > > > producer > > > >> > > should > > > >> > >use a custom qualifier. > > > >> > >- Bridging of the servlet lifecycle events to the CDI event > > > > bus. > > > >> > > > > > >> > > I think these are the most important features which are > required > > > > for > > > >> many > > > >> > > real world applications. > > > >> > > > > > >> > > I'll start working on this on a separate branch on my GitHub > > > > repo. This > > > >> > way > > > >> > > I can prototype the module and then ask for your feedback > before > > > >> merging > > > >> > it > > > >> > > at a later point in time. > > > >> > > > > > >> > > WDYT? Any comments or ideas? :) > > > >> > > > > > >> > > Christian > > > >> > > > > > >> > > > > > >> > > [1] > > > >> > > > > > >> > > > > > >> > > > > >> > > > > > > > > > > http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/seam-servlet-stuff-to-deltaspike-td4653869.html > > > >> > > [2] > > > >> > > > > > >> > > > > > >> > > > > >> > > > > > > > > > > http://apache-deltaspike-incubator-discussions.2316169.n4.nabble.com/Servlet-module-td4654725.html > > > >> > > > > > >> > > -- > > > >> > > Christian Kaltepoth > > > >> > > Blog: http://blog.kaltepoth.de/ > > > >> > > Twitter: http://twitter.com/chkal > > > >> > > GitHub: https://github.com/chkal > > > >> > > > > > >> > > > > >> > > > > > > > > > > > > > > > > -- > > > > Jason Porter > > > > http://en.gravatar.com/lightguardjp > > > > > > > > > > > > > > > -- > > Christian Kaltepoth > > Blog: http://blog.kaltepoth.de/ > > Twitter: http://twitter.com/chkal > > GitHub: https://github.com/chkal > > > -- Christian Kaltepoth Blog: http://blog.kaltepoth.de/ Twitter: http://twitter.com/chkal GitHub: https://github.com/chkal
Re: DISCUSS DeltaSpike-332
Weird if that s true but in such a case app will be constrained too i think Le 2 juin 2013 10:25, "Mark Struberg" a écrit : > > > Pretty often you are not even allowed to change those libs for production. > Sometimes because of legal constructs (ever looked at the Oracle license > for WebLogic?) and sometimes because of company reasons. > > Thus I'm +1 for adding it as _optional_ feature. > > LieGrue, > strub > > > > > > From: Romain Manni-Bucau > >To: dev@deltaspike.apache.org > >Sent: Sunday, 2 June 2013, 8:57 > >Subject: Re: DISCUSS DeltaSpike-332 > > > > > >As said before, if using the javaee7 lib is easy in javaee6 no need of any > >glue. That should be the case for bval, jpa... > >Le 2 juin 2013 03:26, "Jason Porter" a écrit : > > > >> FWIW I'm +1 for the BeanVal stuff and keeping it disabled by default. > Just > >> because Java EE 7 is soon to be released doesn't mean that people will > >> migrate to it over night, as has already been said. I'm sure there are > >> quite a few large corporations still on Java EE 5 and probably will be > for > >> a while. > >> > >> > >> If the coding is minimal to bring some Java EE 7 features to Java EE 6 > >> via DeltaSpike, I don't see a reason not to do this. > >> > >> — > >> Sent from Mailbox for iPhone > >> > >> On Sat, Jun 1, 2013 at 1:55 PM, Gerhard Petracek > >> wrote: > >> > >> > hi thomas, > >> > no - we don't have @Advanced. > >> > (-1 for adding it and therefore -1 for adding parts which would need > >> such a > >> > qualifier.) > >> > regards, > >> > gerhard > >> > 2013/6/1 Thomas Andraschko > >> >> Jep, there will be many EE6 users out there the next 1-3 years. > >> >> > >> >> there are also other possible features: > >> >> - injection in other BV artifacts - e.g. MessageInterpolator > >> >> - method validation (if possible with 1.0 specs) > >> >> > >> >> AFAIK all this features will be available in BV 1.1, so it would be > >> enough > >> >> to create a BV1.0 module. > >> >> > >> >> Is there already something available like @Advanded in DS? > >> >> I personally don't like it. Do we really save performance? > >> >> Probably the best solution is to just activate injection if the > module > >> is > >> >> included. > >> >> > >> >> > >> >> Thats the same with JSF 2.2 ViewScoped. > >> >> How will it be handled in DS? > >> >> > >> >> > >> >> 2013/6/1 Mark Struberg > >> >> > >> >> > As others said, in an EE-6 container you cannot just exchange the > bean > >> >> > validation provider easily. > >> >> > > >> >> > > >> >> > Yes, it's already possible to use the BeanProvider to achieve this > >> goal. > >> >> > But it's also nice if that would work out of the box. > >> >> > An important criteria is of course that it must also work when bean > >> >> > validation-1.1 is available which will do the injection itself. > >> >> > > >> >> > > >> >> > Imo it's mostly a question about what else we like to add into this > >> >> module. > >> >> > > >> >> > LieGrue, > >> >> > strub > >> >> > > >> >> > > >> >> > > >> >> > - Original Message - > >> >> > > From: Gerhard Petracek > >> >> > > To: dev@deltaspike.apache.org > >> >> > > Cc: > >> >> > > Sent: Saturday, 1 June 2013, 20:25 > >> >> > > Subject: Re: DISCUSS DeltaSpike-332 > >> >> > > > >> >> > > hi thomas, > >> >> > > > >> >> > > yes, because we based everything on the jsf 1.2 api. > >> >> > > (~nothing from the jsf2+ api was needed to provide what you get > with > >> >> > codi.) > >> >> > > > >> >> > > @ "...in each validator...": > >> >> > > projects usually don't have that many constraint-validators which > >> need > >> >> > > other services (and if so they might overuse it). > >> >> > > > >> >> > > we should encourage users to move to bv 1.1 asap. > >> >> > > (in case of apache bval we could even provide it for bv 1.0, > since > >> we > >> >> > have > >> >> > > to do it for 1.1+ anyway). > >> >> > > > >> >> > > regards, > >> >> > > gerhard > >> >> > > > >> >> > > > >> >> > > > >> >> > > 2013/6/1 Thomas Andraschko > >> >> > > > >> >> > >> i know what you mean gerhard :) > >> >> > >> but IMO using manual injection or getting the bean via > BeanManager > >> >> > etc. is > >> >> > >> just a "stupid" workaround in each validator. > >> >> > >> > >> >> > >> It would be just user friendly to provide a small module which > >> >> > provides BV > >> >> > >> injection. Also the effort to create this module is very very > low. > >> >> > >> Sure it's not based on the newest technology versions but > there is > >> >> also > >> >> > > a > >> >> > >> JSF 1.2 module in CODI. > >> >> > >> > >> >> > >> > >> >> > >> 2013/6/1 Gerhard Petracek > >> >> > >> > >> >> > >> > @thomas: > >> >> > >> > if you are allowed to use bv 1.1, it should be possible (via > >> >> > >> > default-provider + the corresponding classloading-config for > the > >> >> > > server > >> >> > >> you > >> >> > >> > are using). > >> >> > >> > if you are not allowed to use it, have a look at my initial > >> >> c
Re: DISCUSS DeltaSpike-332
Pretty often you are not even allowed to change those libs for production. Sometimes because of legal constructs (ever looked at the Oracle license for WebLogic?) and sometimes because of company reasons. Thus I'm +1 for adding it as _optional_ feature. LieGrue, strub > > From: Romain Manni-Bucau >To: dev@deltaspike.apache.org >Sent: Sunday, 2 June 2013, 8:57 >Subject: Re: DISCUSS DeltaSpike-332 > > >As said before, if using the javaee7 lib is easy in javaee6 no need of any >glue. That should be the case for bval, jpa... >Le 2 juin 2013 03:26, "Jason Porter" a écrit : > >> FWIW I'm +1 for the BeanVal stuff and keeping it disabled by default. Just >> because Java EE 7 is soon to be released doesn't mean that people will >> migrate to it over night, as has already been said. I'm sure there are >> quite a few large corporations still on Java EE 5 and probably will be for >> a while. >> >> >> If the coding is minimal to bring some Java EE 7 features to Java EE 6 >> via DeltaSpike, I don't see a reason not to do this. >> >> — >> Sent from Mailbox for iPhone >> >> On Sat, Jun 1, 2013 at 1:55 PM, Gerhard Petracek >> wrote: >> >> > hi thomas, >> > no - we don't have @Advanced. >> > (-1 for adding it and therefore -1 for adding parts which would need >> such a >> > qualifier.) >> > regards, >> > gerhard >> > 2013/6/1 Thomas Andraschko >> >> Jep, there will be many EE6 users out there the next 1-3 years. >> >> >> >> there are also other possible features: >> >> - injection in other BV artifacts - e.g. MessageInterpolator >> >> - method validation (if possible with 1.0 specs) >> >> >> >> AFAIK all this features will be available in BV 1.1, so it would be >> enough >> >> to create a BV1.0 module. >> >> >> >> Is there already something available like @Advanded in DS? >> >> I personally don't like it. Do we really save performance? >> >> Probably the best solution is to just activate injection if the module >> is >> >> included. >> >> >> >> >> >> Thats the same with JSF 2.2 ViewScoped. >> >> How will it be handled in DS? >> >> >> >> >> >> 2013/6/1 Mark Struberg >> >> >> >> > As others said, in an EE-6 container you cannot just exchange the bean >> >> > validation provider easily. >> >> > >> >> > >> >> > Yes, it's already possible to use the BeanProvider to achieve this >> goal. >> >> > But it's also nice if that would work out of the box. >> >> > An important criteria is of course that it must also work when bean >> >> > validation-1.1 is available which will do the injection itself. >> >> > >> >> > >> >> > Imo it's mostly a question about what else we like to add into this >> >> module. >> >> > >> >> > LieGrue, >> >> > strub >> >> > >> >> > >> >> > >> >> > - Original Message - >> >> > > From: Gerhard Petracek >> >> > > To: dev@deltaspike.apache.org >> >> > > Cc: >> >> > > Sent: Saturday, 1 June 2013, 20:25 >> >> > > Subject: Re: DISCUSS DeltaSpike-332 >> >> > > >> >> > > hi thomas, >> >> > > >> >> > > yes, because we based everything on the jsf 1.2 api. >> >> > > (~nothing from the jsf2+ api was needed to provide what you get with >> >> > codi.) >> >> > > >> >> > > @ "...in each validator...": >> >> > > projects usually don't have that many constraint-validators which >> need >> >> > > other services (and if so they might overuse it). >> >> > > >> >> > > we should encourage users to move to bv 1.1 asap. >> >> > > (in case of apache bval we could even provide it for bv 1.0, since >> we >> >> > have >> >> > > to do it for 1.1+ anyway). >> >> > > >> >> > > regards, >> >> > > gerhard >> >> > > >> >> > > >> >> > > >> >> > > 2013/6/1 Thomas Andraschko >> >> > > >> >> > >> i know what you mean gerhard :) >> >> > >> but IMO using manual injection or getting the bean via BeanManager >> >> > etc. is >> >> > >> just a "stupid" workaround in each validator. >> >> > >> >> >> > >> It would be just user friendly to provide a small module which >> >> > provides BV >> >> > >> injection. Also the effort to create this module is very very low. >> >> > >> Sure it's not based on the newest technology versions but there is >> >> also >> >> > > a >> >> > >> JSF 1.2 module in CODI. >> >> > >> >> >> > >> >> >> > >> 2013/6/1 Gerhard Petracek >> >> > >> >> >> > >> > @thomas: >> >> > >> > if you are allowed to use bv 1.1, it should be possible (via >> >> > >> > default-provider + the corresponding classloading-config for the >> >> > > server >> >> > >> you >> >> > >> > are using). >> >> > >> > if you are not allowed to use it, have a look at my initial >> >> comments. >> >> > >> > >> >> > >> > @hantsy: >> >> > >> > imo that's exotic anyway and you could still use BeanProvider. >> >> > >> > >> >> > >> > regards, >> >> > >> > gerhard >> >> > >> > >> >> > >> > >> >> > >> > >> >> > >> > 2013/6/1 hantsy >> >> > >> > >> >> > >> > > I noticed JSF 2.2 canceled the DI in JSF components in final >> >> > > Specs, >> >> > >> only >> >> > >> > > support in JSF backend beans
Jsf page and config?
Hi We support a nice jsf navigation (strong typed) but i wonder if we shouldnt look in our config (config resolver) if the page name is not overrided. It would allow to use templates easily. Wdyt? If we do it we need to orefix the properties as for global alternatives.
