I recently had to do a major refactor of an older code base at work. It involved changing a lot of objects, variable names, and where things were stored/retrieved. We're building 2 EJB3 projects with maven and deploying them to glassfish 4 instance.
I'd like to know if it's possible to test for named query validation at build time instead of deploy time. I've spent the last few hours deploying, it failing due to a bad named query, fixing it, redeploying, rinse and repeat. It's getting on my nerves.
Named query errors before deploying could be tracked using Netbeans IDE.
For every named query inside entity beans if it is malformed Netbeans IDE shows a warning message in the line that has named query.
But then one has to visit each entity bean individually but then this practice would save a lot of time over deploying and then finding a error.
I personally find it very convenient.
Related
We have some builds that are failing with variations of this error:
Error creating bean with name 'cartServiceImpl': Unsatisfied dependency expressed through field 'addressServiceClient'; nested exception is org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'addressServiceClient': Bean with name 'addressServiceClient' has been injected into other beans [addressInfoServiceImpl] in its raw version as part of a circular reference, but has eventually been wrapped. This means that said other beans do not use the final version of the bean. This is often the result of over-eager type matching - consider using 'getBeanNamesOfType' with the 'allowEagerInit' flag turned off, for example.
The thing is, we never see this error when we start up the service on our desktops. We only see this error when the build runs on the CI server. In fact, most of the time when we're building the same code, this error does not occur. I have a test case where it runs four concurrent builds of the same branch and commit (targeting for deployment to four different clusters), and sometimes all four succeed, but sometimes one (or even two) of them will fail with this error.
My first theory, when I determined the seeming randomness of this, was that there was some screwy problem with our docker registry or docker cache, which was somehow occasionally giving us an older image (there was a related problem of this nature, for real, several weeks ago). Despite my desire to hang this on another team, I have to assume that there's something we're doing that could be causing this, but perhaps it's random because this is depending on a race condition. I find it hard to believe that Spring bean resolution could have race conditions.
Is there any possibility that an error like this might occur or not occur, depending on race conditions?
We're using Spring Framework 5.0.9 with Spring Boot 2.0.5.
Update:
Note that I still can't repeat this problem with ordinary testing on my laptop, but we were able to extract the jar file constructed on the CI server and download it to my laptop, and then run that directly, and it does get the same error. We compared the contents of the jar file between that jar and a "good" one, and the differences were subtle, no obvious problems that might cause this. We did notice that the AddressServiceClient mentioned in the error is second in the list of classes in the "bad" jar, and far down the list in the "good" jar.
I then thought that perhaps adding #Lazy to the AddressServiceClient class would avoid the problem (not that I don't say "fix"). I tried modifying that "bad" jar file locally, using "zip" to update the jar file with the updated class file, and I found that that resulting jar file did NOT demonstrate the symptom. However, when I finally merged the PR with this change and the builds ran on the CI server, one of them still failed with the same error.
You can use setter injection, it use Spring L3 Cache.
For example:
private TmsOrderService tmsOrderService;
#Autowired
public void setTmsOrderService(TmsOrderService tmsOrderService) {
this.tmsOrderService = tmsOrderService;
}
Spring L3 Cache avoid circular dependencies.
I'm hoping someone can help me figure this one out:
I have two projects on my Eclipse (Spring Tool Suite 3 to be exact) setup:
Our own project with our source code.
Another project from a provider, which our project references as a dependency.
We execute the application locally using a Tomcat v8.5 server.
It was all working fine until recently, when I performed a git pull to update my local code and messed up everything (I'm not sure if I changed something else).
Now, when I try to execute the application, I get the following error (everything compiles and builds correctly):
java.lang.IllegalArgumentException: The servlets named [A] and [A] are both mapped to the url-pattern [/XXXX] which is not permitted.
I didn't make a typo. The error message mentions the same servlet twice, treating it as if it was two different servlets that use the same url-pattern.
Searching for the servlet, I can only find it in a JAR that's downloaded into the local .m2 repository.
I mean, this isn't our servlet, it comes from the provider libraries.
I've seen the other answers to this problem, but those don't work here because:
1) I don't have two servlets steping on each other. There's only one.
2) I can't check if the servlet is defined on the web.xml and on an anotation because it's not ours, but it works for my colleagues so it should be correct.
3) As mentioned before, this servlet is loaded from a dependency, so I can't even try to change anything to try an understand what's happening.
Do you have any idea of what I may have wrong on my setup?
It works correctly for my colleagues, so it isn't a problem with the code.
I've deleted and setup everything from scratch (except deleting the Tomcat server); cleaned and updated the project several times, but I can't get rid of this.
My last attempt was purging and updating the local .m2 repository, but that didn't work either.
Any tips or ideas are much welcomed.
I think you are declaring the servlet mapping both in web.xml and in an annotation, if i remember correctly some tomcat versions allow that.
You said it works for your collegues, check if you all have the same tomcat version.
Having a very weird issue here. I have a list of environments built for dev/test/qa/prod. Each connects to a different database, one corresponding to each environment. When I run the code in dev, everything is great, when I run it in any other environment, I get
Factory method 'sessionFactory' threw exception; nested exception is org.hibernate.tool.schema.spi.SchemaManagementException: Schema-validation: missing table [dbo.Cause_Code]
I would like to now note that this for test/qa/prod, the code is deployed to servers and WORKS. No errors, but running it locally gives me that missing table. That table definately exists and dev/test/qa/prod databases are in the exact same schema state.
You can see here that the table is in the QA database and the IDE sees that:
Adding schema="dbo" to table annotation does nothing, changing hibernate.hbm2ddl.auto to none allows it to build, but all calls fail for the same reason.
I should note that I have tested that is not the environments I built. Dev works, I changed the database connection for that environment to QA and it failed. I also tried adding in the data source directly to hibernate persistance window and that did nothing.
Can someone tell me why the IDE thinks the tabble doesn't exist, but the deployed code works great and the table definitely exists? I have to be missing a simple setting somewhere.
Well, I got tired of trying different things over the last 6 hours and re-installed the IDE. Imported the project which had the shared environment configs already set up. Made no changes and just ran the QA build, worked first try. I guess there was something messed up in the install. No idea why it only affected every environment but dev though. I tried everything form restarting the entire computer to disabling everything to creating an empty project and only the re-install fixed it.
I have the following projects
EJBWebClient
EJBProj
EJBDataAccess
I first created EJBProj. Created EJBDataAccess and added it to EJBProj.ear. Then created EJBWebClient and added it to same ear respectively.
Now from EJBWebClient I look up an EJB inside EJBProj, its looked up and working fine. Inside the bean implementation, I call a DAO inside EJBDataAccess and it throws NoClassDefFound error for that DAO.
Ex. PersonSerivceBean calls PersonDAO.getAllPeople() which is present inside EJBDataAccess. Here is where it throws NoClassDefFound.
I have referenced EJBDataAccess into the buildpath of EJBProj which in turn is referenced for EJBWebClient.
Any idea what's wrong here?
I believe this is a problem with your EJB container. I am not sure what you are using (JBoss, WebSphere, WebLogic, etc), and I am no expert on any of them (we stopped using EJBs a long time ago), but any time you get a NoClassDefFound error, it means the current ClassLoader (the one that loaded the .class your code id "in") cannot find a referenced class.
I know many, many moons ago, JBoss used to have the idea of a "Universal ClassLoader". Basically, all JARs/EARs/WARs were loaded in one big pool. The problem is that a lot of time the code needed different versions of the same JAR, and they were not always compatible. Also, there technically a security risk if someone drops a "custom" class/JAR into the mix ahead of yours. I think it was around JBoss 3.5 that they switched away from the Universal ClassLoader, as I remember our app needed a LOT of work to fix things up to work right. Most of this was a packaging issue for us.
I resolved the issue by manually including the jar names in MANIFEST.MF
I wrote some Hudson plugin's that have changed a bit in terms of the fields and class names (re factoring mostly to clean up the code). Generally speaking everything works fine, but when starting up, Hudson will unmarshall previous plugin data within the build xml.
As most of us know who have done Hudson plugins, hudson will use camel-xstream (or a tool similar) and Hudson will persist the Java objects by marshalling the object's class, state and fields to the build.xml file. If the Object changes and a field name is changed or removed an exception is thrown similar to "Cannot find field x because it does not exist"
My question is - Is there a way to clean up that plugin data so that when I install a new version of the plugin old information will not be persisted and will not cause these unmarshalling exceptions to be thrown?
Thank you
After researching the problem I was trying to resolve I found that Hudson actually has a resolution to this built in.
To be able to resolve start up issues you can do the following:
Go to Manage Hudson link
If it failed to unmarshall objects a
link appears at the top of the page
that reads
'You have data stored in an older format and/or unreadable data.'
Click on Manage button
There will be a list of all failures
press the Discard Unreachable Data button