[Design the new POJO MicroContainer] - NPE in CLSpace
by alesj
DML found this NPE in CLSpace:
- http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4194484#4194484
Take this three config files
| <classloading name="jboss-threads-classloader" version="1.0.0.Alpha" xmlns="urn:jboss:classloading:1.0">
| <capabilities>
| <module name="jboss-threads" version="1.0.0.Alpha"/>
| <package name="org.jboss.threads" version="1.0.0.Alpha"/>
| </capabilities>
| <requirements/>
| </classloading>
|
| <classloading name="jboss-threads-deployer-classloader" version="1.0.0.Alpha" xmlns="urn:jboss:classloading:1.0">
| <requirements>
| <module name="jboss-threads"/>
| <package name="org.jboss.deployers.vfs.deployer.kernel"/>
| <package name="org.jboss.deployers.vfs.spi.deployer"/>
| </requirements>
| </classloading>
|
| <classloading name="jboss-kernel-classloader" version="2.0.0.GA" xmlns="urn:jboss:classloading:1.0" import-all="true">
| <capabilities>
| <package name="org.jboss.deployers.vfs.deployer.kernel"/>
| <package name="org.jboss.deployers.vfs.spi.deployer"/>
| </capabilities>
| <requirements/>
| </classloading>
|
And you end up with
| JBoss-MC-Demo ERROR [04-12-2008 23:56:08] AbstractKernelController - Error resolving dependencies for ClassLoader: name=vfsfile:/C:/projects/demos/sandbox/deployers/ state=Describe mode=Manual requiredState=ClassLoader
| java.lang.NullPointerException
| at org.jboss.classloading.spi.dependency.ClassLoadingSpace.resolve(ClassLoadingSpace.java:325)
| at org.jboss.classloading.spi.dependency.ClassLoadingSpace.joinAndResolve(ClassLoadingSpace.java:122)
| at org.jboss.classloading.spi.dependency.ClassLoadingSpace.joinAndResolve(ClassLoadingSpace.java:169)
| at org.jboss.classloading.spi.dependency.ClassLoadingSpace.resolve(ClassLoadingSpace.java:325)
| at org.jboss.classloading.spi.dependency.Module.resolveModule(Module.java:737)
| at org.jboss.classloading.spi.dependency.RequirementDependencyItem.resolve(RequirementDependencyItem.java:87)
| at org.jboss.dependency.plugins.AbstractDependencyInfo.resolveDependencies(AbstractDependencyInfo.java:143)
| 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.change(AbstractController.java:822)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
| at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:545)
| at org.jboss.demos.bootstrap.MainDeployerHelper.process(MainDeployerHelper.java:86)
|
The cause is the CLMD/module with import-all="true" and this code in Domain::addModule
| // Skip the classloader space checking when it is import all
| if (module.isImportAll() == false)
| {
| ClassLoadingSpace space = new ClassLoadingSpace();
| space.join(module);
| }
|
Module never joins any CLSpace.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4194491#4194491
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4194491
17 years, 4 months
[Design of JBoss Profiler] - NPE taking snapshots
by SteveStair
I'm getting an NPE when I try to take a snapshot.
C:\JBoss Profiler\branches\JBossProfiler2\dist>java -jar jboss-profiler-client.jar -h sstair-dt startProfiler
|
| C:\JBoss Profiler\branches\JBossProfiler2\dist>java -jar jboss-profiler-client.jar -h sstair-dt snapshot
| 2008-12-04 16:14:13,532 ERROR [org.jboss.profiler.client.cmd.Client]
| java.lang.NullPointerException
| at org.jboss.profiler.client.Util.getPrettyName(Util.java:118)
| at org.jboss.profiler.client.SnapshotUtil.dumpFrame(SnapshotUtil.java:389)
| at org.jboss.profiler.client.SnapshotUtil.dumpFrame(SnapshotUtil.java:357)
| at org.jboss.profiler.client.SnapshotUtil.dumpThreads(SnapshotUtil.java:330)
| at org.jboss.profiler.client.SnapshotUtil.dump(SnapshotUtil.java:214)
| at org.jboss.profiler.client.cmd.Client.main(Client.java:264)
|
I built the latest code out of the JBossProfiler2 branch as of December 3rd.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4194483#4194483
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4194483
17 years, 4 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBM 2.0 Strict ordering via ordering groups
by gaohoward
My understanding of message group in JBM 2.0 is that all messages that belong to one message group are guaranteed to be delivered to one consumer. This by definition has nothing to do with strict ordering (or even ordering). They are different concepts. Message groups doesn't necessarily need to observe ordering, and ordering doesn't necessarily enforce single consumer.
Although we can combine the two into one code module, we still can't mingle the two concepts, we still should consider the functionalities for each feature. As for ordering vs message group
1. consumers of strict ordered messages cannot receive second message without first being acknowledged. Consumers of message group can.
2. If we can guarantee strict ordering, there is no need to nail the ordered messages to one consumer. Consider if there are two consumers on one queue that deliver ordered messages. If one consumer gets a failure situation and is not able to consume anymore, the current message will not be acked (or will be rolled back), the other consumer may take over the job (as backup) and continue working (it may call session.recover() first). Will message group allow that happen?
3. If user only wants message group, he shouldn't pay the performance cost brought by strict ordering.
4. In failover and cluster cases, message group and strict ordering are handled differently. Consumer identity is critical for a message group to survive a failure, but sequence is vital to ordering.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4194418#4194418
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4194418
17 years, 4 months
[Design of JBoss Portal] - Design of Portal Deployer
by mwringe
Currently we have all the deployment happen within the portal sar and its tied into the internals of the server. With JBoss AS5 we want to remove this functionality from the sar and use the microcontainer deployment framework.
This will require the addition of a new jboss-portal.deployer that will need to be placed in the /deployers directory of JBoss AS5 along with the jboss-portal.sar in the /deploy directory.
Portlets and our other deployables require a runtime container and these containers have dependencies on other deployables (ie datasources, hibernate, transaction manager). Since these wont be started until after the deployer is running we can't have the containers within the deployer, they must remain in the portal sar.
We could place the deployer inside the sar but this would create a race condition of when the deployer is started and when the deployable is deployed.
Portal Deployer
Will behave like most other deployers and how our current deployment works inside the sar. It will detemine when something of interest is being deployed, parse throught the xml files, gather data about the deployment, manipulate the deployable (adding tlds, the command servlet, ...) and pass the information to the runtime container in the portal sar.
It will add a dependency to the deployable to make sure the runtime container is started before deploying it.
Runtime Container
This is just the various containers we have right now in the sar (instance, portlet, ...). Work is being done here to remove some of the elements to the deployer when required. Still havn't exactly figured out how best to interface the container to the deployer, working right now with mbeans but could also just interface with pojo's running in the microcontainer.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4194401#4194401
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4194401
17 years, 4 months
[Design of Security on JBoss] - Re: JBoss Negotiation - Onto The GA Release
by darran.lofthouse＠jboss.com
"anil.saldhana(a)jboss.com" wrote : Question is whether the ldap login module has usage outside of spnego usecases?
Yes there are uses for this login module anywhere that you would have used one of the other two login modules.
I wrote it so am biased but I believe it is a cleaner implementation by avoiding some of the design restrictions inherited from the 'UsernamePasswordLoginModule' :-) This makes it much easier to separate the users authentication from the roles search logic.
In addition to this the GSSAPI authentication can be used as a different mechanism to remove the password of the user performing the searches and instead place it in a keytab.
The final improvement is in the recursive roles search, now instead of defining how deep to go the module can go as deep as is needed but instead detects looping to prevent an infinity recursive search.
"anil.saldhana(a)jboss.com" wrote :
| The other thing is that 4.x security is frozen. So we are not adding any new features there.
|
| Since negotiation is a drop in use in 4.x and 5.x of AS, I think for the time being, the LM can stay in negotiation.
Ok if we keep it as part of the negotiation project we can then use inheritance if we want to move it later to maintain backwards compatibility.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4194396#4194396
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4194396
17 years, 4 months