primefaces showcase deployed on tomcat style not loaded
Downloaded the source code from below link branch 8.0
https://github.com/primefaces/primefaces-showcase
deployed in tomcat the site is misalligned the styles are not loaded see image attached.
what i am missing why the site is not aligned.
TOMCAT: NO errors in tomcat logs
Glassfish : Error occurred during deployment: Exception while loading the app : java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: org.apache.webbeans.exception.WebBeansDeploymentException: java.lang.NullPointerException. Please see server.log for more deta
Wildfly : {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"primefaces-8.0-SNAPSHOT.war\".undertow-deployment.UndertowDeploymentInfoService" => "java.lang.ClassNotFoundException: org.primefaces.webapp.FileUploadChunksServlet from [Module \"deployment.primefaces-8.0-SNAPSHOT.war\" from Service Module Loader]
Caused by: java.lang.ClassNotFoundException: org.primefaces.webapp.FileUploadChunksServlet from [Module \"deployment.primefaces-8.0-SNAPSHOT.war\" from Service Module Loader]"}}
As long as it deploys in one of the server i am good to go.
So the first thing you did is check if org.primefaces.webapp.FileUploadChunksServlet is actually in the PrimeFaces 8 jar and noticed it is not there. Then you checked the PrimeFaces 8 tag in the source of PrimeFaces and noticed it is also not there. Then you checked the PrimeFaces Master (8.0.x) and noticed it IS there Then you checked the PrimeFaces showcase source to see if there, besides the 8.0.x branch there is a 8.0 tag and noticed tere is not. So your conclusion was that the 8.0.x showcase is up to date with the master and an explicit version of the showcase at the time of releasing PrimeFaces 8.0 is missing.
So you then decided you have three options
In the showcase source, go to the point in time of releasing PF 8 and download the source of that 'snapshot'
File an issue in the PrimeFaces showcase https://github.com/primefaces/primefaces-showcase/issues to request a tag to be made (maybe in retrospect even)
Do both
You then decided to do both and was happy because you could run the showcase locally and made the world a better place since you helped others in the future when the wanted to use the showcase source with a PrimeFaces community release.
Related
I have recently upgraded my EE magento 2.2.6 to 2.3.2. The category pages are are showing error on front-end:
Exception #0 (DomainException): Undefined factory mysql
Also some of my cms pages showing error (possibly due to newly added functionality of Pagebuilder (turning it off doesn't resolve the issue) by Magento):
Argument 2 passed to Magento\PageBuilder\Plugin\Filter\TemplatePlugin::afterFilter() must be of the type string, null given, called in /vendor/magento/framework/Interception/Interceptor.php on line 146
Anyone??
Resolved: For part 1: It was some configuration issue, so I downloaded the core_config_data table and replaced it with my staging site one
For part 2: I was using VladmirPopov webforms extension, it was causing the issue in cms pages, so downloaded the latest version of webforms extension and replaced it.
I have a service fabric application stuck in "Upgrading" mode.
The exception is:
Could not load type 'DB.IAddUser' from assembly 'DB' at
WebApi.Startup.ConfigureServices(IServiceCollection services)
My change was that of renaming the name space, from 'DB' to 'DB.Interfaces'.
This class is only used as a constructor dependency, and registered as such
Startup.cs
services.AddSingleton<IAddUser, AddUser>();
UserController.cs
private IAddUser addUser;
public UserController(IAddUser addUser){
this.addUser = addUser;
}
Why would this cause SF to get stuck?
Additionally, it only got stuck on the last upgrade domain, and not on the others.
I might be mistaken but if upgrade was successful on other upgrade domains then it is not code related issue.
Try to rollback the application upgrade and upgrade again:
Start-ServiceFabricApplicationRollback -ApplicationName fabric:/MyApp
documentation
It turns out that this had nothing to do with service fabric (as expected and as #SteppingRazor said).
The problem seems to be related to MSBuild/Azure devops build task, I had upgraded nuget package
Microsoft.VisualStudio.Azure.Fabric.MSBuild
from 1.6.7 to 1.6.8 and it seems that the build was still using older code (confirmed via a decompiler).
Reverting back to 1.6.7 solved the issue (albeit its just a workaround)
Moving from play 2.2.x to latest activator last night. Downloaded minimal 1.2.10, extracted it in program file (x86)\typesafe... and put the directory into the system path variable. cloned my repository, and when i executed activator run it downloaded the required modules and my app is up and running. All great so far. run works!
Then I tried to create a new app, and activator fails, with the following trace:
Checking for a newer version of Activator (current version 1.2.10)...
... our current version 1.2.10 looks like the latest.
Found previous process id: 9632
FOUND REPO = activator-local # file:////C:/Program%20Files%20(x86)/Typesafe/activator-1.2.10-minimal/repository
Play server process ID is 9760
[info] play - Application started (Prod)
[info] play - Listening for HTTP on /127.0.0.1:8888
[info] a.e.s.Slf4jLogger - Slf4jLogger started
[WARN] [10/30/2014 10:47:13.972] [default-akka.actor.default-dispatcher-2] [ActorSystem(default)] Failed to download new template ca
talog properties: java.lang.IllegalArgumentException: requirement failed: Source file 'C:\Users\admin\.activator\1.2.10\templates\in
dex.db_6e0565f0c8826b17.tmp' is a directory.
[ERROR] [10/30/2014 10:47:13.972] [default-akka.actor.default-dispatcher-2] [akka://default/user/template-cache] Could not find a te
mplate catalog. (activator.templates.repository.RepositoryException: We don't have C:\Users\admin\.activator\1.2.10\templates\cache.
properties with an index hash in it, even though we should have downloaded one
activator.templates.repository.RepositoryException: We don't have C:\Users\admin\.activator\1.2.10\templates\cache.properties with a
n index hash in it, even though we should have downloaded one
at activator.cache.TemplateCacheActor.preStart(TemplateCacheActor.scala:184)
at akka.actor.Actor$class.aroundPreStart(Actor.scala:470)
at activator.cache.TemplateCacheActor.aroundPreStart(TemplateCacheActor.scala:25)
at akka.actor.ActorCell.create(ActorCell.scala:580)
at akka.actor.ActorCell.invokeAll$1(ActorCell.scala:456)
at akka.actor.ActorCell.systemInvoke(ActorCell.scala:478)
at akka.dispatch.Mailbox.processAllSystemMessages(Mailbox.scala:263)
at akka.dispatch.Mailbox.run(Mailbox.scala:219)
at akka.dispatch.ForkJoinExecutorConfigurator$AkkaForkJoinTask.exec(AbstractDispatcher.scala:393)
at scala.concurrent.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260)
at scala.concurrent.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1339)
at scala.concurrent.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979)
at scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)
I've taken a look at several similar issues on SO and elsewhere. I've deleted .activator directory and retried, I've tried this process from behind a proxy and not, as well as offline (surely offline should work!), but it consistently gives the above error. activator ui gives the same error. I'm stuck and any suggestions would be appreciated. (Edit. tried with full activator download, rather than minimal, and I get the same error.)
Look for reasons it might be impossible to create or access 'C:\Users\admin.activator\1.2.10\templates\in
dex.db_6e0565f0c8826b17.tmp' ... maybe a permissions issue?
The failed check is for "is a directory" but that also fails if it just doesn't exist or can't be accessed.
I've upgraded my grails application from 1.3.9 to 2.2.3 and then to 2.3.3. I read the release and upgrade notes for 1.3.9->2.2.3 and then from 2.2.3->2.3.3
I am using OpenJDK 6, Jetty 6 and the plugin jetty 1.1, MySQL 5.5 and I have the connector library under lib
Now my issue is if I run grails clean and then grails run-app the application runs without any problems but if I stop it and run grails run-app again I get a gigantic error (see here: http://pastebin.com/36MpXhir)
I also found that changing something like adding a space somewhere in BuildConfig.groovy (anything that makes it be recompiled) makes the application run normally.
Looking at the stacktrace the first thing that puzzles me is
[02.12.13 16:13:59.919] [main] pool.ConnectionPool Unable to create initial connections of pool.
java.sql.SQLException: com.mysql.jdbc.Driver
at org.apache.tomcat.jdbc.pool.PooledConnection.connectUsingDriver(PooledConnection.java:254)
at org.apache.tomcat.jdbc.pool.PooledConnection.connect(PooledConnection.java:182)
at org.apache.tomcat.jdbc.pool.ConnectionPool.createConnection(ConnectionPool.java:701)
at org.apache.tomcat.jdbc.pool.ConnectionPool.borrowConnection(ConnectionPool.java:635)
at org.apache.tomcat.jdbc.pool.ConnectionPool.init(ConnectionPool.java:486)
at org.apache.tomcat.jdbc.pool.ConnectionPool.<init>(ConnectionPool.java:144)
at org.apache.tomcat.jdbc.pool.DataSourceProxy.pCreatePool(DataSourceProxy.java:116)
at org.apache.tomcat.jdbc.pool.DataSourceProxy.createPool(DataSourceProxy.java:103)
at org.apache.tomcat.jdbc.pool.DataSourceProxy.getConnection(DataSourceProxy.java:127)
at org.springframework.jdbc.datasource.LazyConnectionDataSourceProxy.afterPropertiesSet(LazyConnectionDataSourceProxy.java:162)
There are references to org.apache.tomcat even though I'm using jetty (and removed tomcat from BuildConfig.groovy).
Did anyone else encounter such a problem?
Don't put jar files in the lib directory if they're available in a public Maven repo. It's far better to download jars once and keep them in a local cache, and reuse them as needed.
The MySQL driver is used as the commented-out example in the generated BuildConfig.groovy - just un-comment it :) You might want to bump up the version to the latest, e.g.
dependencies {
runtime 'mysql:mysql-connector-java:5.1.27'
}
This is a good site for finding Maven artifacts: http://mvnrepository.com/artifact/mysql/mysql-connector-java
If you do have a jar that's not in a Maven repo (e.g. one with shared code at your company) then you can put it in the lib directory, but it's not auto-discovered. Run grails compile --refresh-dependencies to get it added to the classpath.
For me same error has occurred while running the Grails Application.Then I debug and view the code history of my code which was committed recently.
From that I found the issue that was:
Inside the controller file I send the instance with-out properly
Eg:
**def list=[personInstance.]---> error occurred.**
**render list as JSON**
Then I correct my mistake-->clean the app --> run the app
Now its working fine.
I have a web server with MONO 2.10.2 (fast-cgi) on a CentOS 6 box. Running a plain-vanilla MVC 3 site works great. However, when I add MySql.Data, it gives me a not-so-helpful error:
System.IO.FileLoadException: The assembly name is invalid.
My DLLs are in the right place. They're referenced properly. Everything has been done correctly, but Mono still complains that it can't find an assembly without telling me which one. The problem occurs after simply adding a reference to MySql.Data and without changing any code. I've looked through the MySql.Data source solution and the references that it needs seem to exist on the web server.
I understand other people have the same problem. I am happy to debug it myself, but I'm new to Mono and I can't figure out how to get a more-detailed error messages. I've checked Mono's site for instructions to enable more detailed logging, but their docs assume a certain base knowledge about Mono that I do not have.
Is there a way to get more detailed information when Mono fails to load an assembly?
I'm not sure if these details matter, but just in case...
- Mono: 2.10.2 (served via fastcgi-mono-server4)
- MySql: Connector.Net 6.4.4.0 (from the v4 set in the .Net & Mono download)
- Webserver: NGINX 1.0.11
- OS: CentOS 6
If you can get a "test case" that compiles to an application, try:
MONO_LOG_LEVEL="debug" MONO_LOG_MASK="dll" mono my_app.exe
Or just temporarily edit your CGI script so that it sets those two variables. Check the logs - you should see what is not loaded propely.