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