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 <john.d.am...@gmail.com> > 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 <rmannibu...@gmail.com> > > > > > 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" <john.d.am...@gmail.com> 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" <strub...@yahoo.de> 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 <rmannibu...@gmail.com> > > > > > > >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" <lightguard...@gmail.com> > 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 > > > > > > >> <gerhard.petra...@gmail.com> 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 <andraschko.tho...@gmail.com> > > > > > > >> >> 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 <strub...@yahoo.de> > > > > > > >> >> > > > > > > >> >> > 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 <gerhard.petra...@gmail.com> > > > > > > >> >> > > 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 < > andraschko.tho...@gmail.com> > > > > > > >> >> > > > > > > > > >> >> > >> 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 < > gerhard.petra...@gmail.com> > > > > > > >> >> > >> > > > > > > >> >> > >> > @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 <han...@yahoo.com.cn> > > > > > > >> >> > >> > > > > > > > >> >> > >> > > I noticed JSF 2.2 canceled the DI in JSF > components > > > in > > > > > > final > > > > > > >> >> > > Specs, > > > > > > >> >> > >> only > > > > > > >> >> > >> > > support in JSF backend beans. > > > > > > >> >> > >> > > > > > > > > >> >> > >> > > MyFaces CODI provides @Advanced for DI in non > > > > contextual > > > > > > >> >> > > object...it is > > > > > > >> >> > >> > > still useful for JSF 2.2...but I do not want to > add > > > > this > > > > > to > > > > > > >> >> > > enable > > > > > > >> >> > >> > > injection on JSF validator, converter, etc. > > > > > > >> >> > >> > > > > > > > > >> >> > >> > > Hantsy > > > > > > >> >> > >> > > On 6/1/2013 22:11, Thomas Andraschko wrote: > > > > > > >> >> > >> > > > Also if BV 1.1 is coming soon, many customers > > can't > > > > > > >> >> > > upgrade to BV 1.1 > > > > > > >> >> > >> > or > > > > > > >> >> > >> > > > JavaEE 7 the next 1-2 years. > > > > > > >> >> > >> > > > So IMO it would be a great feature which shoudl > > be > > > > > > disabled > > > > > > >> >> > > per > > > > > > >> >> > >> > default. > > > > > > >> >> > >> > > > > > > > > > >> >> > >> > > > > > > > > > >> >> > >> > > > 2013/6/1 Romain Manni-Bucau < > > rmannibu...@gmail.com > > > > > > > > > > >> >> > >> > > > > > > > > > >> >> > >> > > >> Idem, not blocking IMO and bval 1.1 is coming > so > > > > would > > > > > > >> >> > > be useless > > > > > > >> >> > >> soon > > > > > > >> >> > >> > > >> Le 1 juin 2013 15:56, "Gerhard Petracek" < > > > > > > >> >> > >> gerhard.petra...@gmail.com> > > > > > > >> >> > >> > a > > > > > > >> >> > >> > > >> écrit : > > > > > > >> >> > >> > > >> > > > > > > >> >> > >> > > >>> hi john, > > > > > > >> >> > >> > > >>> > > > > > > >> >> > >> > > >>> codi doesn't do auto registration. you need > > > > > > >> >> > > @Advanced to enable it. > > > > > > >> >> > >> > > >>> > > > > > > >> >> > >> > > >>> if you aren't allowed to use bv 1.1 right > know, > > > > > > >> >> > > you can just use > > > > > > >> >> > >> > > >>> BeanProvider manually (usually there are just > > few > > > > > > >> >> > >> > constraint-validators > > > > > > >> >> > >> > > >>> which need it at all) > > > > > > >> >> > >> > > >>> or keep what your are using now in parallel > or > > > just > > > > > > >> >> > > copy those few > > > > > > >> >> > >> > > >> classes > > > > > > >> >> > >> > > >>> to your ee6 (only) project. at least in case > of > > > > codi > > > > > > >> >> > > they are quite > > > > > > >> >> > >> > > >>> independent (and in most cases just simple > > > > > > >> >> > > wrappers). -> -1 for > > > > > > >> >> > >> > adding > > > > > > >> >> > >> > > >> it. > > > > > > >> >> > >> > > >>> regards, > > > > > > >> >> > >> > > >>> gerhard > > > > > > >> >> > >> > > >>> > > > > > > >> >> > >> > > >>> > > > > > > >> >> > >> > > >>> > > > > > > >> >> > >> > > >>> 2013/6/1 John D. Ament > > > > > > >> >> > > <john.d.am...@gmail.com> > > > > > > >> >> > >> > > >>> > > > > > > >> >> > >> > > >>>> Hi All > > > > > > >> >> > >> > > >>>> > > > > > > >> >> > >> > > >>>> I wanted to begin introducing some level of > > > > > > >> >> > > BeanValidation > > > > > > >> >> > >> Support. > > > > > > >> >> > >> > > >> The > > > > > > >> >> > >> > > >>>> main goal that I have is to be able to > create > > > > > > >> >> > > CDI aware constraint > > > > > > >> >> > >> > > >>>> validators, let's say you want to validate > > > > > > >> >> > > @NonExistentEmail then > > > > > > >> >> > >> > you > > > > > > >> >> > >> > > >>>> should be able to run a query against your > DB > > > > > > >> >> > > using your CDI > > > > > > >> >> > >> > services > > > > > > >> >> > >> > > >> and > > > > > > >> >> > >> > > >>>> determine if the given email is already > > present > > > > > > >> >> > > or not. > > > > > > >> >> > >> > > >>>> > > > > > > >> >> > >> > > >>>> To do this, both Seam3 and CODI introduced a > > CDI > > > > > > >> >> > > aware > > > > > > >> >> > >> > > >> ConstraintFactory. > > > > > > >> >> > >> > > >>>> When it creates an instance the instance > is a > > > > > > >> >> > > CDI object, so it > > > > > > >> >> > >> has > > > > > > >> >> > >> > > >> full > > > > > > >> >> > >> > > >>>> access to @Inject fields. I'd like to bring > > > > > > >> >> > > this type of > > > > > > >> >> > >> > > functionality > > > > > > >> >> > >> > > >>>> over to DS. > > > > > > >> >> > >> > > >>>> > > > > > > >> >> > >> > > >>>> The point where the two diverge is that CODI > > > > > > >> >> > > does an auto > > > > > > >> >> > >> > registration > > > > > > >> >> > >> > > >>>> whereas Seam3 does a registration via > > > > > > >> >> > > validation.xml. As far as I > > > > > > >> >> > >> > > >> know, > > > > > > >> >> > >> > > >>>> CDI already allows the injection of > Validator > > > > > > >> >> > > and ValidatorFactory > > > > > > >> >> > >> > > >>> (though > > > > > > >> >> > >> > > >>>> the OWB guys can tell me if they disagree). > > > > > > >> >> > >> > > >>>> > > > > > > >> >> > >> > > >>>> Please let me know if anyone has concerns > with > > > > > > >> >> > > adding this. Yes, > > > > > > >> >> > >> I > > > > > > >> >> > >> > > >>> realize > > > > > > >> >> > >> > > >>>> that this functionality is in bean val 1.1, > > but > > > > > > >> >> > > not everyone can > > > > > > >> >> > >> > > >> upgrade > > > > > > >> >> > >> > > >>> to > > > > > > >> >> > >> > > >>>> bean val 1.1 yet. > > > > > > >> >> > >> > > >>>> > > > > > > >> >> > >> > > >>>> John > > > > > > >> >> > >> > > >>>> > > > > > > >> >> > >> > > > > > > > > >> >> > >> > > -- > > > > > > >> >> > >> > > Hantsy Bai > > > > > > >> >> > >> > > Blog:http://hantsy.blogspot.com > > > > > > >> >> > >> > > LinkedIN:http://www.linkedin.com/in/hantsy > > > > > > >> >> > >> > > > > > > > > >> >> > >> > > > > > > > >> >> > >> > > > > > > >> >> > > > > > > > > >> >> > > > > > > > >> >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
