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