February 2008 - jboss-dev-forums - Jboss List Archives

[Design of POJO Server] - Re: Facelets scanning for .taglib.xml is broken in trunk

by alesj

"scott.stark(a)jboss.org" wrote : getAlternativeJarFile is broken for vfs urls. It all comes down to no ability to navigate a URL and no ClassLoader.getResources with a regex pattern, so they have to try to guess what type of URL it is. | But why this worked before, with VFS and the new CL both already being used. Why it stopped with your war CL changes? "scott.stark(a)jboss.org" wrote : | There needs to be a better servlet api to access resources inside of a war for code like this to work in general. | Couldn't agree more. But we are constantly seeing this problem, so it won't go away soon. :-( "scott.stark(a)jboss.org" wrote : | Is there any point that the tag lib urls can be overriden? | Pete or. any other Seam/Facelet guru? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4127195#4127195 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4127195

18 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: Facelets scanning for .taglib.xml is broken in trunk

by scott.stark＠jboss.org

getAlternativeJarFile is broken for vfs urls. It all comes down to no ability to navigate a URL and no ClassLoader.getResources with a regex pattern, so they have to try to guess what type of URL it is. There needs to be a better servlet api to access resources inside of a war for code like this to work in general. Is there any point that the tag lib urls can be overriden? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4127184#4127184 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4127184

18 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: FIELD granularity web session replication tests

by bstansberry＠jboss.com

Problem seems to arise from the FieldBasedSessionPassivationTestCase.testRedeploy() test, which deploys a war, undeploys it and deploys it again. Trying to store a Person object in PojoCache fails after the redeploy: | 2008-02-06 14:07:02,175 ERROR [org.apache.catalina.connector.CoyoteAdapter] An exception or error occurred in the container during the request processing | java.lang.NullPointerException | at org.jboss.test.cluster.web.aop.Person._getInstanceAdvisor(Person.java) | at org.jboss.cache.pojo.impl.AdvisedPojoHandler.get(AdvisedPojoHandler.java:60) | at org.jboss.cache.pojo.impl.PojoCacheDelegate.getObjectInternal(PojoCacheDelegate.java:350) | at org.jboss.cache.pojo.impl.PojoCacheDelegate.getObject(PojoCacheDelegate.java:102) | at org.jboss.cache.pojo.impl.PojoCacheImpl.getObject(PojoCacheImpl.java:207) | at org.jboss.cache.pojo.impl.PojoCacheImpl.getObject(PojoCacheImpl.java:202) | at org.jboss.cache.pojo.impl.PojoCacheImpl.org$jboss$cache$pojo$impl$PojoCacheImpl$find$aop(PojoCacheImpl.java:192) | at org.jboss.cache.pojo.impl.PojoCacheImpl$PojoCacheImplAdvisor.find_N_7063709169143275953(PojoCacheImpl$PojoCacheImplAdvisor.java) | at org.jboss.cache.pojo.impl.PojoCacheImpl.find(PojoCacheImpl.java) | at org.jboss.cache.pojo.impl.PojoCacheImpl.find(PojoCacheImpl.java:184) | at org.jboss.web.tomcat.service.session.JBossCacheService.getPojo(JBossCacheService.java:760) | at org.jboss.web.tomcat.service.session.FieldBasedClusteredSession.populateAttributes(FieldBasedClusteredSession.java:179) | at org.jboss.web.tomcat.service.session.JBossCacheClusteredSession.initAfterLoad(JBossCacheClusteredSession.java:67) | at org.jboss.web.tomcat.service.session.JBossCacheManager.loadSession(JBossCacheManager.java:1224) | at org.jboss.web.tomcat.service.session.JBossCacheManager.findSession(JBossCacheManager.java:933) | at org.apache.catalina.connector.Request.doGetSession(Request.java:2306) | at org.apache.catalina.connector.Request.getSessionInternal(Request.java:2225) | at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:394) | at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:90) | at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:96) | at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) | at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) | at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157) | at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) | at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:309) | at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) | at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601) | at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) | at java.lang.Thread.run(Thread.java:595) | Trying to track down what's happening here in a debugger, I see that the Person class being manipulated is the old class from before the redeploy. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4127183#4127183 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4127183

18 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: Facelets scanning for .taglib.xml is broken in trunk

by alesj

The current version of Facelets used in our Seam Booking example is 1.1.14: - https://facelets.dev.java.net/servlets/ProjectDocumentList?folderID=3635&... I think it all starts from FaceletViewHandler.buildView(). Calling DefaultFaceletFactory.getFacelet. This call another getFacelet method, which calls createFacelet. Which invokes compiler.compile(url, alias), that does initialize(). Compiler.initialize invokes TagLibraryConfig.loadImplicit, which does the actual search Classpath.search(cl, "META-INF/", ".taglib.xml"). The cl variable is context classloader. ClassPath class: | public final class Classpath { | | /** | * | */ | public Classpath() { | super(); | } | | public static URL[] search(String prefix, String suffix) throws IOException { | return search(Thread.currentThread().getContextClassLoader(), prefix, | suffix); | } | | public static URL[] search(ClassLoader cl, String prefix, String suffix) throws IOException { | Enumeration[] e = new Enumeration[] { | cl.getResources(prefix), | cl.getResources(prefix + "MANIFEST.MF") | }; | Set all = new LinkedHashSet(); | URL url; | URLConnection conn; | JarFile jarFile; | for (int i = 0, s = e.length; i < s; ++i) { | while (e.hasMoreElements()) { | url = (URL) e.nextElement(); | conn = url.openConnection(); | conn.setUseCaches(false); | conn.setDefaultUseCaches(false); | if (conn instanceof JarURLConnection) { | jarFile = ((JarURLConnection) conn).getJarFile(); | } else { | jarFile = getAlternativeJarFile(url); | } | if (jarFile != null) { | searchJar(cl, all, jarFile, prefix, suffix); | } else { | searchDir(all, | new File(URLDecoder.decode(url.getFile(), | "UTF-8")), | suffix); | } | } | } | URL[] urlArray = (URL[]) all.toArray(new URL[all.size()]); | return urlArray; | } | | private static void searchDir(Set result, File file, String suffix) | throws IOException { | if (file.exists() && file.isDirectory()) { | File[] fc = file.listFiles(); | String path; | URL src; | for (int i = 0; i < fc.length; i++) { | path = fc.getAbsolutePath(); | if (fc.isDirectory()) { | searchDir(result, fc, suffix); | } else if (path.endsWith(suffix)) { | // result.add(new URL("file:/" + path)); | result.add(fc.toURL()); | } | } | } | } | | /** For URLs to JARs that do not use JarURLConnection - allowed by | * the servlet spec - attempt to produce a JarFile object all the same. | * Known servlet engines that function like this include Weblogic | * and OC4J. | * This is not a full solution, since an unpacked WAR or EAR will not | * have JAR "files" as such. | */ | private static JarFile getAlternativeJarFile(URL url) throws IOException { | String urlFile = url.getFile(); | // Trim off any suffix - which is prefixed by "!/" on Weblogic | int separatorIndex = urlFile.indexOf("!/"); | | // OK, didn't find that. Try the less safe "!", used on OC4J | if (separatorIndex == -1) { | separatorIndex = urlFile.indexOf('!'); | } | | if (separatorIndex != -1) { | String jarFileUrl = urlFile.substring(0, separatorIndex); | // And trim off any "file:" prefix. | if (jarFileUrl.startsWith("file:")) { | jarFileUrl = jarFileUrl.substring("file:".length()); | } | return new JarFile(jarFileUrl); | } | return null; | } | | private static void searchJar(ClassLoader cl, Set result, JarFile file, | String prefix, String suffix) throws IOException { | Enumeration e = file.entries(); | JarEntry entry; | String name; | while (e.hasMoreElements()) { | try { | entry = (JarEntry) e.nextElement(); | } catch (Throwable t) { | continue; | } | name = entry.getName(); | if (name.startsWith(prefix) && name.endsWith(suffix)) { | Enumeration e2 = cl.getResources(name); | while (e2.hasMoreElements()) { | result.add(e2.nextElement()); | } | } | } | } | | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4127178#4127178 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4127178

18 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Another startup time regression

by scott.stark＠jboss.org

After updating my trunk workspace today, I'm seeing another regression in startup time vs where we were earlier this week. I had been down to just under 20s, but now its back over 30: | 12:31:27,792 INFO [TransactionManagerService] Binding TransactionManager JNDI Reference | 12:31:50,207 INFO [AspectDeployer] Deploying xml into org.jboss.aop.AspectManager@133092e for BaseClassLoader@1d66d03{vfsfile:/home/svn/JBossHead/jboss-head/build/output/jboss-5.0.0.Beta4/server/default/deploy/ejb3-interceptors-aop.xml}12:31:50,533 INFO [MailService] Mail Service bound to java:/Mail | ... | 12:31:56,441 INFO [AjpProtocol] Starting Coyote AJP/1.3 on ajp-127.0.0.1-8009 | 12:31:56,454 INFO [ServerImpl] JBoss (Microcontainer) [5.0.0.Beta4 (build: SVNTag=JBoss_5_0_0_Beta4 date=200802061227)] Started in 33s:157ms | The regression time is all between the TransactionManagerService and AspectDeployer, where the delay between the info msgs is 13 seconds. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4127169#4127169 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4127169

18 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: FIELD granularity web session replication tests

by bstansberry＠jboss.com

It's definitely related to multiple tests. Just running FieldBasedTestCase once, it passes. But run it after the FieldBasedSessionPassivationTestCase w/o restarting the servers, and problems appear. The testsuite runs ScopedFieldBasedTestCase in between; that doesn't cause any issue. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4127165#4127165 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4127165

18 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: property values in ManagementViewImpl.applyTemplate

by scott.stark＠jboss.org

I'll look more into this as soon as I commit the datasource properties type of value changes. We talked about this being related to the problem I'm seeing with properties from runtime=true ManagedObjects not getting mapped to the configuration object. I'm not sure its exactly the same issue, but we need to clarify naming across configuration, runtime and templates to be sure this works for any type of deployment model. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4127139#4127139 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4127139

18 years, 2 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: WS 2.1.0 METRO integration with JBOSS AS 4.2.2

by heiko.braun＠jboss.com

Yes, but's it's actually revision 5572 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4127131#4127131 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4127131

18 years, 2 months

1
0
0 / 0

[Design of POJO Server] - Re: FIELD granularity web session replication tests

by bstansberry＠jboss.com

The recent changes fixed a bunch of the FIELD tests. Still a lot of failures though. I'm researching, but FYI here's what I see. The setSession.jsp call fails with this: | 2008-02-06 11:07:38,354 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/http-field].[jsp]] Servlet.service() for servlet jsp threw exception | java.lang.NullPointerException | at org.jboss.test.cluster.web.aop.Person.name_w_$aop(Person.java) | at org.jboss.test.cluster.web.aop.Person.<init>(Person.java:38) | at org.apache.jsp.setSession_jsp._jspService(setSession_jsp.java:65) | at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) | at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) | at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:369) | at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:337) | at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:266) | at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) | at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) | at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) | at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) | at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) | at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) | at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) | at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) | at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:189) | at org.jboss.web.tomcat.service.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:89) | at org.jboss.web.tomcat.service.session.BatchReplicationClusteredSessionValve.invoke(BatchReplicationClusteredSessionValve.java:102) | at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433) | at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:90) | at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:96) | at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) | at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) | at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157) | at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) | at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:309) | at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) | at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601) | at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) | at java.lang.Thread.run(Thread.java:595) | I'm pretty sure this has something to do with the fact that another test has run earlier, org.jboss.test.cluster.defaultcfg.web.field.test.ScopedFieldBasedTestCase. That test basically does the same thing, but includes a loader-repository element in jboss-web.xml. The Person, etc. types used in both tests have the same FQCN. I'm going to experiment with running one of the failing tests by itself; if it passes but then fails in combination with another, that confirms my theory. I'll also decompile the bytecode enhanced classes to try and get a feel for the cause of the NPE. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4127112#4127112 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4127112

18 years, 2 months

1
0
0 / 0

[Design the new POJO MicroContainer] - AbstractManagedObjectFactory needs to be refactored

by scott.stark＠jboss.org

The current org.jboss.managed.plugins.factory.AbstractManagedObjectFactory has too much going on to be reusable. In particular, the InstanceClassFactory(Serializable), ManagedObjectPopulator(Serializable) parameterized interfaces cannot be changed by subclasses, for example, this cannot be done: | public class LocalDSInstanceClassFactory extends AbstractManagedObjectFactory | implements InstanceClassFactory<LocalDataSourceDeploymentMetaData> | { | ... | } | ... | ManagedObjectFactory mof = ManagedObjectFactory.getInstance(); | LocalDSInstanceClassFactory icf = new LocalDSInstanceClassFactory(); | mof.setInstanceClassFactory(LocalDataSourceDeploymentMetaData.class, icf); | Either the AbstractManagedObjectFactory needs to keep the interface paramterization, or the default implementations need to be plugins with different base classes. I'm working on the latter local to the jbossas/connector project to validate what works. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4127111#4127111 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4127111

18 years, 2 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums February 2008