[Design of JBoss Wiki] - Re: Installation of JBoss Wiki
by PeterJ
Finally! Success!
Here is what I did:
1) Downloaded the source from subversion:
svn co https://anonsvn.jboss.org/repos/portletswap/contrib/wikiPortlet/tags/1.0 wiki_1.0
2) Manually installed several missing libraries:
mvn install:install-file -DgroupId=jboss -DartifactId=portal-core-lib -Dversion=1.0 -Dpackaging=jar -Dfile=%PORTAL_HOME%\jboss-portal.sar\lib\portal-core-lib.jar
| mvn install:install-file -DgroupId=jboss -DartifactId=portal-portlet-lib -Dversion=1.0 -Dpackaging=jar -Dfile=%PORTAL_HOME%\jboss-portal.sar\lib\portal-portlet-lib.jar
| mvn install:install-file -DgroupId=jboss -DartifactId=portal-identity-lib -Dversion=1.0 -Dpackaging=jar -Dfile=%PORTAL_HOME%\jboss-portal.sar\lib\portal-identity-lib.jar
| mvn install:install-file -DgroupId=jboss -DartifactId=portal-common-lib -Dversion=1.0 -Dpackaging=jar -Dfile=%PORTAL_HOME%\jboss-portal.sar\lib\portal-common-lib.jar
| mvn install:install-file -DgroupId=jboss -DartifactId=jboss-portlet-api-lib -Dversion=1.0 -Dpackaging=jar -Dfile=%PORTAL_HOME%\jboss-portal.sar\lib\jboss-portlet-api-lib.jar
| mvn install:install-file -DgroupId=jboss -DartifactId=jboss-ejb3x -Dversion=1.0 -Dpackaging=jar -Dfile=%JBOSS_HOME%\client\jboss-ejb3x.jar
| mvn install:install-file -DgroupId=jboss -DartifactId=jboss-mail -Dversion=1.0 -Dpackaging=jar -Dfile=%JBOSS_HOME%\server\default\lib\mail.jar
| mvn install:install-file -DgroupId=jboss -DartifactId=activation -Dversion=1.0 -Dpackaging=jar -Dfile=%JBOSS_HOME%\server\default\lib\activation.jar
| mvn install:install-file -DgroupId=jboss -DartifactId=portal-api-lib -Dversion=2.7.1 -Dpackaging=jar -Dfile=%PORTAL_HOME%\jboss-portal.sar\lib\portal-api-lib.jar
| mvn install:install-file -DgroupId=jboss -DartifactId=jboss-jmx -Dversion=1.0 -Dpackaging=jar -Dfile=%JBOSS_HOME%\lib\jboss-jmx.jar
| mvn install:install-file -DgroupId=jboss -DartifactId=portlet-api -Dversion=2.4.0 -Dpackaging=jar -Dfile=%PORTAL_HOME%\jboss-portal.sar\lib\portlet-api.jar
| mvn install:install-file -DgroupId=jboss -DartifactId=jboss-j2ee -Dversion=1.0 -Dpackaging=jar -Dfile=%JBOSS_HOME%\server\default\lib\jboss-j2ee.jar
| mvn install:install-file -DgroupId=jboss -DartifactId=jboss-annotations-ejb3 -Dversion=1.0 -Dpackaging=jar -Dfile=%JBOSS_HOME%\client\jboss-annotations-ejb3.jar
(Looks like the forum is wrapping the lines - each 'mvn' command should be on a single line)
%JBOSS_HOME% is where the JBoss AS 4.2.3.GA binary zip file was installed.
%PORTAL_HOME% is where the Portal 2.7.1.GA binrary was unpacked. If using the Portal + AS bundle, PORTAL_HOME is %JBOSS_HOME%\server\default.
Linux readers can adjust the syntax accordingly.
3) Commented out the jboss-ejb3 dependency in all five pom.xml files. There is a story behind this - some of the names used for JAR files in the POMs don't match the names o JAR files in either AS or Portal. So when in doubt, I commented out the dependency. If the build failed, I looked up the JAR containing the missing class and manually installed it. There was never an error based on the missing jboss-ejb3 dependency.
By the way, why are the dependencies mentioned in the base pom.xml repeated in the pom.xml files in the subdirectories? Those subdirectory POMs reference the base POM as a parent and thus pick up the dependencies automatically.
4) I then cd'ed into the wiki-common, wiki-management, wiki-test and forge-wiki directories and ran:
mvn install
in each one. I had to run it twice for wiki-common, once with 'packaging' set to 'pom' and once with it set to 'jar'.
5) I then changed the version number of the dependency of portal-identify-lib in the base pom.xml to 1.0 (from 2.7.1) to match the version number in wiki-common/pom.xml.
By the way, it would be nice if the versions were correct! Hardly any of the JARs identified as being at version 1.0 are at that version. If the proper version and artifact names were used, they could be pulled from the JBoss Maven repository instead of
being manually installed.
6) Then from the base directory I ran:
mvn install
The build then completed successfully.
I recommend that someone on the Wiki team make the corrections to the pom.xml files that I mentioned above. And in the base pom.xml, change the header comment to this:
<!--
| * JBoss, Home of Professional Open Source
| * Copyright 2009, JBoss Inc., and individual contributors as indicated
| * by the @authors tag. See the copyright.txt in the distribution for a
| * full listing of individual contributors.
| *
| * This is free software; you can redistribute it and/or modify it
| * under the terms of the GNU Lesser General Public License as
| * published by the Free Software Foundation; either version 2.1 of
| * the License, or (at your option) any later version.
| *
| * This software is distributed in the hope that it will be useful,
| * but WITHOUT ANY WARRANTY; without even the implied warranty of
| * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
| * Lesser General Public License for more details.
| *
| * You should have received a copy of the GNU Lesser General Public
| * License along with this software; if not, write to the Free
| * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
| * 02110-1301 USA, or see the FSF site: http://www.fsf.org.
|
|
| BUILD INSTRUCTIONS
| ==================
|
| 1) Manually install various artifacts
|
| Before you run the build, you must manully install a number of JAR files
| into your local Maven repository. The JARs you need to install are:
|
| From JBoss Portal:
| portal-core-lib.jar, version 1.0
| portal-portlet-lib, version 1.0
| portal-common-lib.jar, version 2.7.1
| portal-identity-lib.jar, version 1.0
| jboss-portlet-api-lib.jar, version 1.0
| jboss-ejb3x.jar, version 1.0
| jboss-mail.jar, version 1.0
| activation.jar, version 1.0
| portal-api-lib.jar, version 2.7.1
| jboss-jmx.jar, version 1.0
| portlet-api.jar, version 2.4.0
| jboss-j2ee.jar, version
| jboss-annotations-ejb3
|
| Here is an example for installing portal-core-lib.jar, install the other
| JAR files using similar command. (If you miss one, or mistype it, Maven
| will remind you of the syntax for installing a JAR file.) In the example,
| <portal-home> is the location where the Portal binary zip file was unpacked.
|
| mvn install:install-file -DgroupId=jboss -DartifactId=portal-core-lib -Dversion=1.0 -Dpackaging=jar -Dfile=<portal-home>/jboss-portal.sar/lib/portal-core-lib.jar
|
| Note that some of the dependencies are located in JBoss AS, not in Portal.
|
|
| 2) Build the prerequisite projects
|
| You must build the wiki-common, wiki-management and wiki-test artifacts first.
| To do this, open a command line the corresponding directory, for example:
|
| cd <wiki-src-dir>/wiki-common
|
| where <wiki-src-dir> is the base directory of the wiki source, and enter:
|
| mvn install
|
|
| 3) Build the wiki
|
| Open a command line at the directory containing this POM and enter:
|
| mvn install
|
| author: Piergiorgio Lucidi
| -->
By the way, the licensing text should really follow what is recommended for LGPL.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4217193#4217193
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4217193
17 years
[Design of POJO Server] - Re: AS 5 not reliably picking up changes in exploded EAR
by alesj
"max.andersen(a)jboss.com" wrote : I still don't understand why Seam needs to have a tmp for exploded deployment ?
It's a very simple problem. ;-)
Some apps, in this case it was Seam Wicket example app,
still want to do some resources lookup at undeploy.
An undeploy which was triggered by the app's dir/archive deletion from deploy/.
But since the app was deleted there is nowhere to do the lookup from.
Unless you do a temp copy. ;-)
And this is what we used to do, and what most app servers still do.
We changed this behavior due to the VFS usage which can handle nested jars in memory.
But we still provide a way to do temp - via jboss-structure.xml.
In this case Seam guys found it to verbose to have to include jboss-structure.xml
in any Seam deployment in JBoss5, hence this feature was developed
== able to recognize deployments and modify the ContextInfo info before the actual/real deployment phase kicks in.
We did temps by-default before, in 4.x, but I don't know how
Tomcat/JBossWeb handled this, since afaik WarDeployer didn't monitor all non-metadata files.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4217186#4217186
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4217186
17 years
[Design of JBoss Identity] - Re: descentralized identity Federation component
by aamonten
"anil.saldhana(a)jboss.com" wrote : It is just one of the use cases possible.
|
| It should be pretty straight forward to implement this use case as a valve/servlet filter and tie it with the container security.
|
| The question would be what trust information gets associated with the user name that floated in? Maybe the digital signature of the sender with whom the IDP has trust relationship.....
I'm more concerned about the user identifier, SP-1 could have use the username identifier while SP-2 could use the email as the identifier then there is a problem by matching the identifiers.
Does any know if there are a standard for these? I have been looking at the "Name identifier Management Profile" but not sure if it's the adequate, as I see it to open and want avoid creating something none standard.
Maybe a kind of alias service that manage the mappings of ids related to unique identifier...
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4217129#4217129
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4217129
17 years
[Design the new POJO MicroContainer] - Re: Generated Classes not found if they do not match any of
by kabir.khan＠jboss.com
Here is the first problem, when running with importAll=false
| public void testExplicitImportGenerateClassInExistingPackage() throws Exception
| {
| runExplicitImportGenerateClass(EXISTING_PACKAGE, true);
| }
|
| private void runExplicitImportGenerateClass(GeneratedClassInfo info, boolean expectSuccess) throws Exception
| {
| ClassLoadingMetaDataFactory factory = ClassLoadingMetaDataFactory.getInstance();
| String dynamicClassRoot = getDynamicClassRoot();
| VFSClassLoaderFactory a = new VFSClassLoaderFactory("a");
| a.getRoots().add(getRoot(A.class));
| a.getCapabilities().addCapability(factory.createPackage(A.class.getPackage().getName()));
| KernelDeployment depA = install(a);
|
| VFSClassLoaderFactory b = new VFSClassLoaderFactory("b");
| b.getRoots().add(getRoot(B.class));
| b.getRoots().add(dynamicClassRoot);
| b.getCapabilities().addCapability(factory.createPackage(B.class.getPackage().getName()));
| b.getRequirements().addRequirement(factory.createRequirePackage(A.class.getPackage().getName()));
| KernelDeployment depB = install(b);
|
| ...
| }
|
When deploying this, I get the following error
| 1218 ERROR [AbstractKernelController] Error resolving dependencies for Installed: name=b:0.0.0$MODULE state=Start
| java.lang.IllegalStateException: VFSClassLoaderPolicyModule b:0.0.0 cannot be added because it is exports package newpackage which conflicts
| with VFSClassLoaderPolicyModule a:0.0.0
| at org.jboss.classloading.spi.dependency.ClassLoadingSpace.join(ClassLoadingSpace.java:223)
| at org.jboss.classloading.spi.dependency.ClassLoadingSpace.joinAndResolve(ClassLoadingSpace.java:120)
| at org.jboss.classloading.spi.dependency.ClassLoadingSpace.joinAndResolve(ClassLoadingSpace.java:169)
| at org.jboss.classloading.spi.dependency.ClassLoadingSpace.resolve(ClassLoadingSpace.java:326)
| at org.jboss.classloading.spi.dependency.Module.resolveModule(Module.java:909)
| at org.jboss.classloading.spi.dependency.RequirementDependencyItem.resolve(RequirementDependencyItem.java:91)
| at org.jboss.dependency.plugins.AbstractDependencyInfo.resolveDependencies(AbstractDependencyInfo.java:138)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1103)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1039)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:774)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
| at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBean(AbstractKernelDeployer.java:319)
| at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBeans(AbstractKernelDeployer.java:297)
| at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deploy(AbstractKernelDeployer.java:130)
| at org.jboss.kernel.plugins.deployment.BasicKernelDeployer.deploy(BasicKernelDeployer.java:76)
| at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:88)
| at org.jboss.test.kernel.junit.MicrocontainerTestDelegate.deploy(MicrocontainerTestDelegate.java:358)
| at org.jboss.test.kernel.junit.MicrocontainerTest.deploy(MicrocontainerTest.java:368)
| at org.jboss.test.classloading.vfs.metadata.VFSClassLoadingMicrocontainerTest.install(VFSClassLoadingMicrocontainerTest.java:208)
| at org.jboss.test.classloading.vfs.metadata.test.GeneratedClassesUnitTestCase.runExplicitImportGenerateClass(GeneratedClassesUnitTestCase.j
| ava:171)
| at org.jboss.test.classloading.vfs.metadata.test.GeneratedClassesUnitTestCase.testExplicitImportGenerateClassInExistingPackage(GeneratedCla
| ssesUnitTestCase.java:88)
| ...
|
I was not really expecting problems at this stage, I was writing this test to investigate if we would need a GlobalRequirementsProvider. The package "newpackage", mentioned in the trace, is one of the global capabilities. Can really 2 loaders with importAll=false not export the same package, or have I done something wrong?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4217096#4217096
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4217096
17 years