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