I am relatively new to ALfresco, but have alreay installed the 5.0.d Version once experimentilly and now try to set up the 201510 EA Version.
I am struggling with the set up of the Web Quick Start.
I noted from the earlier installation that the meat data need to have the real domain name instead of the localhost / 127.0.0.1 IP adress.
Unfortunately I can't find the meta settings anymore.
I have tried also to install the system with the domain name instead of the localhost during the setup, but no difference. All I get is
Spring Surf 1.0.0
Spring Surf has been installed at this location.
A root page has not been defined.
What do I need to do to get this working?
EDIT
Found the metadata at the Quick Start Editorialand Quick Start Live folder. Then the metadate (or Eigenschaften in German) can be edited. Nevertheless it did not solve the issue yet (as it did in 5.0.0.d)
EDIT-2
I have found the following warnings in the webquickstart.log:
19:20:27,889 WARN [org.alfresco.wcm.client.impl.WebSiteServiceImpl] Received a request for unrecognised host+port: sbd.mydom.tld:8080/wcmqs
19:20:27,890 WARN [org.alfresco.wcm.client.interceptor.ApplicationDataInterceptor] Received request for which no configured website can be found: sbd.mydom.tld:8080
19:20:27,890 ERROR [org.alfresco.wcm.client.exceptionresolver.RepositoryExceptionResolver] org.alfresco.wcm.client.exception.PageNotFoundException: sbd.mydom.tld:8080
org.alfresco.wcm.client.exception.PageNotFoundException: sbd.mydom.tld:8080
at org.alfresco.wcm.client.interceptor.ApplicationDataInterceptor.preHandle(ApplicationDataInterceptor.java:79)
at org.springframework.web.servlet.HandlerExecutionChain.applyPreHandle(HandlerExecutionChain.java:134)
at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:928)
at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:867)
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:953)
at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:844)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:620)
at org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:829)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:748)
at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:486)
at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:411)
at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:338)
at org.tuckey.web.filters.urlrewrite.NormalRewrittenUrl.doRewrite(NormalRewrittenUrl.java:213)
at org.tuckey.web.filters.urlrewrite.RuleChain.handleRewrite(RuleChain.java:171)
at org.tuckey.web.filters.urlrewrite.RuleChain.doRules(RuleChain.java:145)
at org.tuckey.web.filters.urlrewrite.UrlRewriter.processRequest(UrlRewriter.java:92)
at org.tuckey.web.filters.urlrewrite.UrlRewriteFilter.doFilter(UrlRewriteFilter.java:389)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:504)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:170)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:950)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:421)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1074)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:611)
at org.apache.tomcat.util.net.AprEndpoint$SocketWithOptionsProcessor.run(AprEndpoint.java:2403)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)
https://forums.alfresco.com/forum/developer-discussions/web-content-services/awe-not-working-42a-10242012-1328
Does this link help? Someone has the same problem as you (I think it's the same) and he writes that he solved it with:
I just realized I need to edit properties on the folders that contain the content. I changed the IP address and it now works on my external IP address.
I hope this helps.
Have you imported a demo site or created from scratch the necessary index.html page? Try to use the following link: http://docs.alfresco.com/5.1/tasks/WQS-import-demodata.html
There are two classes involved here:
ApplicationDataInterceptor.java
WebSiteServiceImpl.java
ApplicationDataInterceptor calls WebSiteServiceImpl to get the site based on host, port and context-path.
As you can see, WebSiteServiceImpl executes a CMIS query to find all the registered sites:
private static final String QUERY_WEB_ROOTS = "select f.cmis:objectId, w.ws:hostName, w.ws:hostPort, t.cm:title, t.cm:description, w.ws:webAppContext, w.ws:siteConfig "
+ "from cmis:folder as f "
+ "join ws:website as w on w.cmis:objectId = f.cmis:objectId "
+ "join cm:titled as t on t.cmis:objectId = f.cmis:objectId";
If you set the log level for WebSiteServiceImpl to debug, you will find this query in the log.
You can then execute it in the query browser and see what it returns. You should see your site. Based on the error returned, it seems that there is another site configured with the same ip/port/context and that does not have a root index page.
I have now installed the latest Version of Alfresco (201602) and got everything to work as expected.
The major difference to the previous installation was that I did not change the
Webserver-Domäne: [127.0.0.1]:
from the preset value.
During the last installation I tried to set the domain-name here, which seems that this was the issue.
As a second step needed to set the domain information in the meta-data of the folder Quick Start Editorial as described above.
Now it works.
Related
I have installed cave-repository to Fuse and afterwards I created a new repository. When I try to reach repository via http, I receive the following error from undertow.
NOTE: I did no change to undertow settings. It is a default fuse package.
java.lang.IllegalStateException: UT010026: Async is not supported for
this request, as not all filters or Servlets were marked as supporting
async at
io.undertow.servlet.spec.HttpServletRequestImpl.startAsync(HttpServletRequestImpl.java:1023)
at
org.apache.karaf.cave.repository.service.maven.MavenServlet.doGet(MavenServlet.java:285)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:645) at
javax.servlet.http.HttpServlet.service(HttpServlet.java:750) at
io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
at
io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
at
io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
at
io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at
org.ops4j.pax.web.service.undertow.internal.Context$1.lambda$wrap$0(Context.java:615)
at
io.undertow.servlet.handlers.RedirectDirHandler.handleRequest(RedirectDirHandler.java:68)
at
io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
at
io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at
io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at
io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
at
io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
at
io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
io.undertow.servlet.handlers.SessionRestoringHandler.handleRequest(SessionRestoringHandler.java:119)
at
io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:269)
at
io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:78)
at
io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:133)
at
io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:130)
at
io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
at
io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at
io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249)
at
io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:78)
at
io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:99)
at
io.undertow.server.Connectors.executeRootHandler(Connectors.java:376)
at
io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
I tried the same steps (installing and creating cave repository) in karaf with jetty, and everything works fine there.
During the search in google, I have found the following page in redhat but due to subscription I am not able to see the content.
https://access.redhat.com/solutions/4222431
The problem is that (as I commented under https://ops4j1.jira.com/browse/PAXWEB-1254) Cave's MavenServlet is registered using plain HttpService.registerServlet() without specifying async supported flag. It works with Jetty only by coincidence (doesn't work - as expected - with pax-web-tomcat and pax-web-undertow).
Karaf Cave should either use Pax Web specific WebContainer extension to org.osgi.service.http.HttpService or register the servlet using annotations.
We'll continue the discussion in Karaf/Cave project.
BLUF: I'm getting a stackoverflow starting my Liberty server with a single war file before it reaches any of my code. I can't debug what is causing the problem. I tried adding trace statements to server.xml but never got files I could interpret (were binary) and trying to Open Log Files had no choices available (greyed out). If anyone has any ideas how to determine what is causing the stack overflow I'd appreciate the help. Thanks in advance. My code does use #Inject but I don't think this is the issue as all works fine if I move code from a separate project/jar into the war project.
Running wlp 17.0.0.1 when starting a single war using shared libraries to jar files in a single directory, I get a StackOverflowError before any of my code is reached (based on setting breakpoints in the RestServicesApplication and any static initializers).
This problem only occurs when some classes have been moved to a separate project and therefore into a separate jar (e.g., moving them back to the war project allows all to run fine).
I've checked that all classes and methods references are public. I'm calling public static methods in the new jar file.
I'm not sure how to figure out the problem as no references to my code are in the ffdc files in the stack traces.
I've verified the needed classes are in the jar file and there are no duplicate classes being referenced.
Essentially, the class in the war file has a call like:
public static JSONObject processFuzzyMatch(ID session,
ID userID, JSONObject request)
throws ILDException {
try {
return NLUFuzzyEntityMatcherFunction.processFuzzyMatch(request);
} catch (Exception e) {
throw new ILDException(e);
}
}
and NLUFuzzyEntityMatcherFunction is in the jar file declared as:
public static JSONObject processFuzzyMatch(JSONObject request)
throws Exception
Here is an example of the reported problem with the last line repeating (for the stack overflow...)
Stack Dump = com.ibm.ws.container.service.state.StateChangeException: java.lang.StackOverflowError
at com.ibm.ws.container.service.state.internal.ApplicationStateManager.fireStarting(ApplicationStateManager.java:33)
at com.ibm.ws.container.service.state.internal.StateChangeServiceImpl.fireApplicationStarting(StateChangeServiceImpl.java:51)
at com.ibm.ws.app.manager.module.internal.DeployedAppInfoBase.preDeployApp(DeployedAppInfoBase.java:376)
at com.ibm.ws.app.manager.module.internal.DeployedAppInfoBase.deployApp(DeployedAppInfoBase.java:403)
at com.ibm.ws.app.manager.war.internal.WARApplicationHandlerImpl.install(WARApplicationHandlerImpl.java:66)
at com.ibm.ws.app.manager.internal.statemachine.StartAction.execute(StartAction.java:141)
at com.ibm.ws.app.manager.internal.statemachine.ApplicationStateMachineImpl.enterState(ApplicationStateMachineImpl.java:1253)
at com.ibm.ws.app.manager.internal.statemachine.ApplicationStateMachineImpl.run(ApplicationStateMachineImpl.java:866)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.StackOverflowError
at java.io.UnixFileSystem.getBooleanAttributes0(Native Method)
at java.io.UnixFileSystem.getBooleanAttributes(UnixFileSystem.java:242)
at java.io.File.exists(File.java:819)
at com.ibm.wsspi.kernel.service.utils.FileUtils$3.run(FileUtils.java:88)
at com.ibm.wsspi.kernel.service.utils.FileUtils$3.run(FileUtils.java:85)
at java.security.AccessController.doPrivileged(Native Method)
at com.ibm.wsspi.kernel.service.utils.FileUtils.fileExists(FileUtils.java:85)
at com.ibm.ws.artifact.loose.internal.LooseArchive$DirEntryInfo.matches(LooseArchive.java:232)
at com.ibm.ws.artifact.loose.internal.LooseArchive$DirEntryInfo.matches(LooseArchive.java:207)
at com.ibm.ws.artifact.loose.internal.LooseArchive.getEntry(LooseArchive.java:782)
at com.ibm.ws.artifact.overlay.internal.DirectoryBasedOverlayContainerImpl.getEntry(DirectoryBasedOverlayContainerImpl.java:838)
at com.ibm.ws.adaptable.module.internal.AdaptableContainerImpl.getEntry(AdaptableContainerImpl.java:113)
at com.ibm.ws.jsp.taglib.TagLibraryCache.loadWebInfMap(TagLibraryCache.java:613)
at com.ibm.ws.jsp.taglib.TagLibraryCache.loadWebInfMap(TagLibraryCache.java:629)
at com.ibm.ws.jsp.taglib.TagLibraryCache.loadWebInfMap(TagLibraryCache.java:629)
(above line repeats due to stack overflow)
This is a known problem on Liberty. The fix to that problem will be available on Liberty 17.0.0.3.
You can use some workarounds:
I assume you have a folder named WEB-INF within a jar. Change the folder name to something else. That folder name causes the JSP engine to go to the web module's WEB-INF (scanning everything again!), instead of the jar's WEB-INF.
Try setting the JSP configuration parameter disableTldSearch to true; this may be troublesome if you are using custom tag libraries. With the property set, all your custom TLD files need to be declared in the web.xml.
Disable CDI; I know this may not be possible for you as you mentioned you are using injections.
Somehow I screwed up the project settings for the jar project (likely because I'd copied the pom.xml from the Web project and forgot to change it to jar...). This may have resulted in the screwed up xml file in the /apps folder with an embedded reference to a non-existent war file (see below):
<?xml version="1.0" encoding="UTF-8"?>
<archive>
<archive targetInArchive="/WEB-INF/lib/ildMicroServices-1.0.0-SNAPSHOT.jar">
<dir sourceOnDisk="/csnext/ild/ild_framework/ildMicroServices/WebContent" targetInArchive="/"/>
<dir sourceOnDisk="/csnext/ild/ild_framework/ildMicroServices/target/classes" targetInArchive="/WEB-INF/classes"/>
<dir sourceOnDisk="/csnext/ild/ild_framework/ildMicroServices/target/test-
classes" targetInArchive="/WEB-INF/classes"/>
</archive>
<dir sourceOnDisk="/csnext/ild/ild_framework/ildRESTServices/target/m2e-wtp/web-resources" targetInArchive="/"/>
<dir sourceOnDisk="/csnext/ild/ild_framework/ildRESTServices/WebContent" targetInArchive="/"/>
<dir sourceOnDisk="/csnext/ild/ild_framework/ildRESTServices/target/classes" targetInArchive="/WEB-INF/classes"/>
<dir sourceOnDisk="/csnext/ild/ild_framework/ildRESTServices/target/test-classes" targetInArchive="/WEB-INF/classes"/>
</archive>
By deleting this embedded archive the problem went away.
I only found this after upgrading from Neon to Oxygen, and 17.0.0.1 to 17.0.0.2 and when setting up the new server using the old server's artifacts, I noticed the xml file in /apps didn't look correct.
I hope this helps somebody.
I want to send my weblogic log to syslog. here is what I have done so far.
1.Included following log4j.properties in managed server classpath -
log4j.rootLogger=DEBUG,syslog
log4j.appender.syslog=org.apache.log4j.net.SyslogAppender
log4j.appender.syslog.Threshold=DEBUG
log4j.appender.syslog.Facility=LOCAL7
log4j.appender.syslog.FacilityPrinting=false
log4j.appender.syslog.Header=true
log4j.appender.syslog.SyslogHost=localhost
log4j.appender.syslog.layout=org.apache.log4j.PatternLayout
log4j.appender.syslog.layout.ConversionPattern=[%p] %c:%L - %m%n
2. added following command to managed server arguments -
-Dlog4j.configuration=file :<path to log4j properties file> -Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4JLogger -Dweblogic.log.Log4jLoggingEnabled=true
3. Added wllog4j.jar and llog4j-1.2.14.jar into domain's lib folder.
4.Then, from Admin console changed logging information by doing the following. "my_domain_name"--->Configuration--->Logging--->(Advanced options)-->Logging implementation: Log4J
Restart managed server.
I used this as refernce. But didnt get anaything in syslog(/var/log/message). What am I doing wrong?
I would recommend a couple items to check:
Remove the space in DEBUG, syslog in the file
Your last two server arguments have a space between the - and the D so make sure that wasn't just a copy and paste error in this post.
Double check that the log files are in the actual classpath.
Double check from a ps command, that the -D options made it correctly into the start command that was executed.
Make sure that the managed server has a copy of the JARs correctly as they would get synchornized from admin during the restart.
Hopefully something in there will help or give an idea of what to look for.
--John
I figured out the problem. My appender was working fine, the problem was in rsyslog.conf. Just uncommented following properties
# Provides UDP syslog reception
#$ModLoad imudp
#$UDPServerRun 514
We were appending the messages, but the listner was abesnt, so it didnt knew what to do with it.
and from *.debug;mail.none;authpriv.none;cron.none /var/log/messages it figures out where to redirect any (debug in this case) information to messages file.
I am using liferay 5.2 sp 2 on weblogic 10.
I need liferay-yuicompressor.jar file in the lib folder of domain.
I am tryign to create .jar file as per described on this link:
http://issues.liferay.com/browse/LPS-3169
When i ant build-yui i am facing below exception.
get-swing-ex:
[mkdir] Created dir: D:\Liferay Material\GOSI\liferay-portal-src-5.2.2\liferay-portal-src-5.2.2\portal-impl\20130301133406114\rhino1_6R7\toolsrc\com\liferay\mozilla\javasc
ript\tools\debugger\downloaded
[get] Getting: http://java.sun.com/products/jfc/tsc/articles/treetable2/downloads/src.zip
[get] To: D:\Liferay Material\GOSI\liferay-portal-src-5.2.2\liferay-portal-src-5.2.2\portal-impl\20130301133406114\rhino1_6R7\toolsrc\com\liferay\mozilla\javascript\tool
s\debugger\downloaded\swingExSrc.zip
[get] http://java.sun.com/products/jfc/tsc/articles/treetable2/downloads/src.zip permanently moved to http://www.oracle.com/technetwork/java/index.html
[unzip] Expanding: D:\Liferay Material\GOSI\liferay-portal-src-5.2.2\liferay-portal-src-5.2.2\portal-impl\20130301133406114\rhino1_6R7\toolsrc\com\liferay\mozilla\javascri
pt\tools\debugger\downloaded\swingExSrc.zip into D:\Liferay Material\GOSI\liferay-portal-src-5.2.2\liferay-portal-src-5.2.2\portal-impl\20130301133406114\rhino1_6R7\toolsrc\co
m\liferay\mozilla\javascript\tools\debugger\downloaded
BUILD FAILED
As per my understanding it is trying to get the .zip file from http://java.sun.com/products/jfc/tsc/articles/treetable2/downloads/src.zip
but it is no longer available and moved to http://www.oracle.com/technetwork/java/index.html
I need your help in getting liferay-yuicompressor.jar file.
Please help me out...
Nakul, I was responding your other post facing exception while deploying liferay on weblogic. Sorry I misunderstood your last comment on that post, as I used LifeRay 6.x, not 5.x.
How about we disable the minification for the runtime so that you do not need to use the liferay-yuicompressor.jar.
You can add the below to portal-ext.properties
javascript.fast.load=false
theme.css.fast.load=false
If you still prefer to do minification for performance reason, you can do it during the build time as described here: http://yui.github.com/yuicompressor/. Between runtime and build time minification, I always prefer build time.
try to comment
<ant antfile="toolsrc/build.xml" target="compile"/>
into the root build.xml
more than that if you will have similiar problems with xbean.jar just set
without-xmlimpl: no
into build.properties file
I've got very simple .WAR containing example servlet. I'm able to deploy it in servicemix using the following command:
osgi:install file:///home/seiho/apache-servicemix-4.4.2/deploy/TestServlet.war?Bundle-SymbolicName=TestServlet&Webapp-Context=/TestServlet
And then see it in my browser. But only with full path to a file, e.g.: localhost:8080/TestServlet/index.html or localhost:8080/TestServlet/TestServlet (my servlet is TestServlet class).
I'd like to launch the index.html page automatically after entering: localhost:8080/TestServlet
how to do it?
MORE IMPORTANT
I need a way to convert the .WAR file or servlet project (I've got the sources) so that new .WAR file can be auto-deployed by copying it to $SERVICEMIX_HOME/deploy directory.
I've tried editing the MANIFEST.MF file, but with no success. Probably I'm doing something wrong.
Thanks for any advice/help.
To be recognised as a wab, you need to add a context path header to your manifest:
Web-ContextPath: TestServlet
It's working now! I was doing my MANIFEST.MF according to this page: http://team.ops4j.org/wiki/display/ops4j/Pax+Web+Extender+-+War+-+OSGi-fy
The problem was that for some reason "Bundle-Version: 1.0" line was required as opposed to optional as stated on that page.
Honestly, just adding the Bundle-Version fix-it.
I knew it was something wrong with the MANIFEST.MF and after Holly Cummins' question I played with it a bit more. Thanks Holly.
I still can't do anything with the manual site launching (have to manually enter the index.html).
http://localhost:8080/TestServlet/ gives me this:
HTTP ERROR 404
Problem accessing /TestServlet/. Reason:
Not Found
Powered by Jetty://
http://localhost:8080/TestServlet/index.html gives me proper site.