[Design of JBoss Wiki] - Re: [[/wiki]] Exception starting filter wikiFileAccessFilter
by davidmboon
I also have the same problem with jboss 4.0.5GA, with the ejb3 rc8 applied.
| 12:54:49,757 INFO [TomcatDeployer] deploy, ctxPath=/wiki, warUrl=.../tmp/deploy/tmp52342wiki.ear-contents/wiki-exp.war/
| 12:54:50,835 ERROR [[/wiki]] Exception starting filter wikiFileAccessFilter
| java.lang.NoClassDefFoundError: org/jboss/wiki/WikiSession
| at java.lang.Class.getDeclaredConstructors0(Native Method)
| at java.lang.Class.privateGetDeclaredConstructors(Class.java:2357)
| at java.lang.Class.getConstructor0(Class.java:2671)
| at java.lang.Class.newInstance0(Class.java:321)
| at java.lang.Class.newInstance(Class.java:303)
| at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:210)
| at org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:304)
| at org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterConfig.java:77)
| at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3634)
| at org.apache.catalina.core.StandardContext.start(StandardContext.java:4217)
| at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759)
| at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739)
| at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
|
|
I'm using a server copied from the "all" configuration.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4030721#4030721
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4030721
19 years
[Design of JBoss Build System] - Re: javaee versioning
by pgier
Common might be a little bit different situation. Since there doesn't seem to be a need for aggregate releases of common, the parts are treated like separate projects. So they each have their own trunk/branches/tags. I'm thinking of removing the aggregate build part of common altogether.
For javaee, if you want to have both individual component releases and aggregate, svn should be fine the way it is now. Subversion doesn't have a problem with tagging sub directories into the tags and branches directories. So you could have:
| tags/
| |--jboss-ejb-api-3.0/
| |--jboss-jacc-api-1.1/
| |--jboss-perisistence-api-1.0/
| \--jboss-javaee-1.0
|
And you could do the same thing with the branches directory.
Maven can also handle this pretty easily. If you put the svn URL in the parent project, the subprojects will inherit this, and they will all point to the same place. Then the release plugin can create the tags for you when you do a release.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4030683#4030683
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4030683
19 years
[Design of JBoss Build System] - javaee versioning
by wolfc
"Emmanuel" wrote : Imagine in a year and a half we want to provide a Java Persistence 2.0 preview. The monolithic javaee.jar will pose problem. That's why I had in mind to keep the subspec in separate jars.
This is covered by the different sub modules. But one thing I haven't thought of yet is how to keep track of versions in svn?
The tree is currently:
javaee/trunk/[module]
With things coming like:
javaee/branches/Branch_1_4/[module]
javaee/branches/Branch_5/[module]
But actually the versions are different:
jboss-ejb-api = 3.0
jboss-jacc-api = 1.1
jboss-perisistence-api = 1.0 or 3.0 (don't know which one)
jboss-transaction-api = 1.0.1
etc.
I think I saw a different layout in common, but is there a blueprint which covers this scenario?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4030666#4030666
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4030666
19 years
[Design of Clustering on JBoss (Clusters/JBoss)] - Re: HASingleton and partition merges
by adrian＠jboss.org
"galder.zamarreno(a)jboss.com" wrote : I think it needs configuring too but I would leave it as off by default so that it mantains previous 4.0.x behaivour and then customers can set it to true for recommended services, such as HA-JMS.
|
| What complications can you see in backporting this? The patch instructions could explain the flag and give the recommendations.
If you make it configurable it should be *on* by default.
The main use of the deploy-hasingleton is for HA-JMS which needs this behaviour
(restart on merge).
The same will be true of any singleton that is not totally in-memory.
If somebody doesn't want this behaviour, they can always create their
own deploy-hasingleton-ignore-merge with the MBean configured not to restart.
The real solution (which I've advocated for a while) is for this behaviour
to be defined on the MBean so you could do something like:
| <mbean ...>
| <ha-singleton partition="DefaultPartition" restart-on-merge="true"/>
|
This is something that can be done in JBoss5 with the decorators (aspects)
and using an annotation rather than specific xml.
| <bean ...>
| <annotation>@org.jboss.cluster.annotation.HASingleton</annotation>
|
| public @interface HASingleton
| {
| String partiionName() default "DefaultPartition";
| boolean restartOnMerge() default true;
| }
|
| and even "programmatically":
|
| @HASingleton
| public class Queue {}
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4030645#4030645
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4030645
19 years
[Design of Clustering on JBoss (Clusters/JBoss)] - Re: HASingleton and partition merges
by bstansberry＠jboss.com
The complication with backporting is:
1) New config flag == change to mbean interface
2) Change to interface is illegal in a CP, hence have to create a new interface and new probably a trivial new class that exposes it (I'm too lazy to go beyond a StandardMBean approach.
3) Don't want to change deploy-hasingleton-service.xml to use this new class/interface, as that's too big a change for a CP (changing config file could break people who've already altered it.)
All this is resolvable, it's just extra hassle. And the result is that a fix will be in the codebase, but to take advantage of it users will have to make manual configuration changes.
(BTW, users can't set the flag to true for HA-JMS per se. They can set it to true for the jboss.ha:service=HASingletonDeployer service, which in essence means setting it to true for the entire deploy-hasingleton directory. If they wanted the behavior only for HA-JMS and had other deploy-hasingleton content, they'd have to separate the content into another dir and create a parallel HASingletonController to deploy that dir.)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4030622#4030622
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4030622
19 years