November 2006 - jboss-dev-forums - Jboss List Archives

[Design of JBoss jBPM] - problem with jbossretro on tomcat

by tom.baeyens＠jboss.com

David, could you have a look at the following issue ? I have tried to deploy the standard java web console on tomcat. I added the necessary libraries (amongst others, jbossretro-rt.jar, backport-consurrent.jar and commons-logging.jar) to the console.war and then delpoyed to tomcat. Then i got this stack trace: I used tomcat 6.0.0. SEVERE: Exception sending context initialized event to listener instance of class com.sun.faces.config.ConfigureListener | java.lang.LinkageError: loader constraints violated when linking javax/el/ExpressionFactory class | at com.sun.faces.config.ConfigureListener.registerELResolverAndListenerWithJsp(ConfigureListener.java:1712) | at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:513) | at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3826) | at org.apache.catalina.core.StandardContext.start(StandardContext.java:4335) | at org.apache.catalina.startup.HostConfig.checkResources(HostConfig.java:1104) | at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1202) | at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:292) | at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) | at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1305) | at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1569) | at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1578) | at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1558) | at java.lang.Thread.run(Thread.java:595) | Do you have the same problem deploying on tomcat ? Could you have a look at this ? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985356#3985356 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985356

19 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Name change for PojoCache annotation

by ben.wang＠jboss.com

Since 1.4 release, I have created two annotations: @PojoCacheable and @InstanceOfPojoCacheable for POJO declaration. The first denotes that such that POJO will be instrumented while the second one means any sub-class will also be intrumented. The original intention originally was to put a wrapper around the JBoss Aop @Prepare and @Prepare(... instanceof(...)) such that user won't have to use the JBoss Aop annotation directly. Still the user needs to exercise the PojoCache.attach api to attach the POJO, e.g. That is, our model is minimal API (instead of API-less where all you need to do is declare the POJO annotation). Now, Bela has suggested we change the name (see part of: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985215#3985215). Since 2.0 is not out yet, this may be a good time to discuss the name change. Obvious candidate is perhaps @Replicated and @InstanceOfReplicated. Originally, I have thought about it but felt that it is a bit over-loaded (since user would then expect this is api-less). But if people think it is more appropriate, I can certainly oblige. Thoghts? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985339#3985339 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985339

19 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Re: static field replication in PojoCache

by bela＠jboss.com

anonymous wrote : | Yeah, agreed then. I am still thinking if there is a better way to support it other than explicit api. | Yes, agreed. I don't see the need for this API. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985338#3985338 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985338

19 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Re: static field replication in PojoCache

by bela＠jboss.com

anonymous wrote : | But keep in mind that by default, we skip replicating static, final, and transient now. If we want to change the default to replicate static field, question is how often people want to replicate static field? If often, then yes, default is good. But otherwise, default may not be that good. | By default we need to replicate static fields, don't replicate final and transient (or @transient) fields. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985336#3985336 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985336

19 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Problem with VFS AbstractJarHandler / JarEntryHandler

by scott.stark＠jboss.org

There is a problem with consistency of locating files in packed vs unpacked jars if jar entry .getName() values include the trailing slash since the corresponding file in the unpacked version does not. The VirtualFile.toURL() is what is not including the trailing '/'? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985333#3985333 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985333

19 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Re: static field replication in PojoCache

by ben.wang＠jboss.com

"bela(a)jboss.com" wrote : | I think this is not intuitive: @PojoCacheable replicates *all* variables, so static vars should be included. | You can exclude static vars using the transient keyword or @transient annotation. But keep in mind that by default, we skip replicating static, final, and transient now. If we want to change the default to replicate static field, question is how often people want to replicate static field? If often, then yes, default is good. But otherwise, default may not be that good. And what about final field default? anonymous wrote : | Why should only 1 PojoCache be allowed to have static var replication inside the same VM ? This sounds like an arbitrary restriction... Yeah, agreed then. I am still thinking if there is a better way to support it other than explicit api. anonymous wrote : | Still much better than @PojoCacheable, which is horrible I will create a new thread to discuss this then. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985332#3985332 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985332

19 years, 5 months

1
0
0 / 0

[Design of JBoss Portal] - Re: how to avoid hard-coded calls to jsp.

by bdaw

Wrong place. This is design forum. Moving this topic to the user forum. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985328#3985328 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985328

19 years, 5 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: JBAS-3766, port the webservice deployer

by jason.greene＠jboss.com

"scott.stark(a)jboss.org" wrote : Another issue I'm seeing with the current JAXWSDeployerJSE is that it is trying to use the deployment class loader before the class loading deployers have committed. The JAXWSDeployerJSE should be before the WarDeployer, not just after the JBossWebAppParsingDeployer as use of the deployment class loader requires the deployer to be after the CLASSLOADER_DEPLOYER. I created a JBoss5VDFDeployerOrdering page as a reference for how to choose the deployer relative order: | http://wiki.jboss.org/wiki/Wiki.jsp?page=JBoss5VDFDeployerOrdering | I took a look at fixing this, but the classloader constructed by the deployer fails because the jar url returned from the VFS refers to "!/WEB-INF/classes instead of "!/WEB-INF/classes/". See the follow post for more info: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985315#3985315 -Jason View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985317#3985317 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985317

19 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Problem with VFS AbstractJarHandler / JarEntryHandler

by jason.greene＠jboss.com

When a URL is built for a JAR entry that is a directory, the trailing slash is removed. Without the slash, URLClassLoader will reject it as a valid classpath entry. Can anyone see a problem with using the non-stripped entry name for construction of the URL? This would also fix the following: | // Question: Why doesn't this work properly? | // URL url = new URL(parent.toURL(), entry.getName()); | URL url = getURL(parent, entryName); | -Jason View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985315#3985315 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985315

19 years, 5 months

1
0
0 / 0

[Design of JBoss Portal] - how to avoid hard-coded calls to jsp.

by sandeepjha18

hi I am developing a portlet wherein I am using PortletRequestDispatcher to call my jsp files. Here I have to hard-code the name of jsp file which I want to call. I want to avoid that. Is there any other way to do this like in struts we have a struts-config.xml where we enter the jsp pages in forwards. Any similar mechanism or any other solution?? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3985307#3985307 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3985307

19 years, 5 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 November 2006