[Design of JBoss Portal] - DnD defect in JBP2.7.1
by vivek_saini07
Drag and Drop property is not working in JBP2.7.1 as expected. For some portlets it does not work, but when some specific portlets gets added on that same page, DND starts working as expected. Like when we add Weather/CMS Portlet on page first time DnD does not work at all but when 'Identity user portlet' gets added on the page, DnD starts working.
We can simulate this by following these steps:
1) Download new bundled version of JBossPortal 2.7.1 and strat the server
2) Enable DnD property.
3) Go to admin portal.
4) select CMS page. Notice that 'Manage Content' woindow is not dragable.
5) select Members page. Notice that window added on the page is dragable.
6) Now to prove the point further, create a new page in admin portal itself. This new page has 2 column layout by default.
7) Add a weather portlet on this page. Notice that DnD is not working
8) Add CMS portlet on this page. Notice that DnD is not working
9) Add Identity user portlet on this page. Notice that DnD is working fine.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209514#4209514
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209514
17 years, 1 month
[Design of JBoss internal QA (Test Suite)] - Re: AS testsuite using wrong jvm to exectute tests?
by emuckenhuber
"akostadinov" wrote : In my experience, to use java reliably, you need to have JAVA_HOME set to the jdk/jre directory.
|
| AFAIU you, you are running Sun JVM to compile AS and tests but you are running it with JAVA_HOME set to the openjdk location. Is that correct? I don't think that can work properly. It could if you have -Djava.home=<jdk.path>/jre.
| But in this case wouldn't it be easier to just set -Djunit.jvm ?
I have JAVA_HOME pointing to my jdk directory. So AS is compiled and run with this jdk.
The only problem is that JAVA_HOME is not used for junit tests. The one on the system $PATH is used,
as the default value of ${junit.jvm} is net setUp propery.
This means in my case that JAVA_HOME is pointing to my sun-jdk-1.5 and
the junit test is run with openjdk 1.6 (as this is the one in my system $PATH),
although it should use the one from JAVA_HOME.
So i have to set this ${junit.jvm} property to get "[testsuite]$ ./build.sh tests-profileservice" working.
Just because it's using the wrong jdk :)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209513#4209513
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209513
17 years, 1 month
[Design of JBoss Web Services] - Re: Dynamic Endpoint Deployment
by richard.opalka＠jboss.com
In this thread we're talking about the following part of the stack trace:
MainDeployerImpl.deploy(Deployment...) line: 445
DynamicEndpointDeploymentAspect.create(Deployment) line: 88
DeploymentAspectManagerImpl.deploy(Deployment) line: 115
DeploymentAspectHttpServer.publish(HttpContext, Endpoint) line: 91
EndpointImpl.publish(Object) line: 172
EndpointServlet.init(ServletConfig) line: 70
StandardWrapper.loadServlet() line: 1048
StandardWrapper.load() line: 950
StandardContext.loadOnStartup(Container[]) line: 4122
StandardContext.start() line: 4421
TomcatDeployment.performDeployInternal(WebApplication, String, String) line: 315
TomcatDeployment.performDeploy(WebApplication, String) line: 147
TomcatDeployment(AbstractWarDeployment).start(DeploymentUnit, JBossWebMetaData) line: 461
WebModule.startModule() line: 118
WebModule.start() line: 97
anonymous wrote :
| Hot-deploying the war seems to go through the deployer chain twice. Once, when it goes through usual hot-deployment (See Stack1 below), then it does something in the tomcat/service-layer, I guess to deploy the WS endpoint (See Stack2 below).
|
Correct, it goes through deployers chain twice. This is evident from the stack trace above ;)
anonymous wrote :
| Now the problem is that the first time it deploys this, it correctly includes a Module attachment with the deploymentunit which links the classloader to a scoped classloading domain called "vfszip:/Users/kabir/sourcecontrol/jbossas/Branch_5_0/testsuite/output/lib/jaxws-endpoint-servlet.war" (See variables1 below).
Correct because first walk through deployers chain is pure web app deployment (Servlet in war)
anonymous wrote :
| When it deploys the second time, it incorrectly includes a Module attachment with the deploymentunit linking the classloader to the main/non-scoped classloading domain called DefaultDomain.
We do construct "minimal Deployment" needed to pass the deployers chain programatically (because we're calling MainDeployer.deploy() from servlet code).
Regarding the classloading issue you're facing it's because
our DynamicEndpointDeploymentAspect puts
Servlet context classloader to the constructed "minimal Deployment".
anonymous wrote :
| Somehow the new deployment created internally needs to either include the original Module,
|
I don't know how to achieve that because web service endpoint is published from servlet and we do not have access to DeploymentUnit from it :(
anonymous wrote : or the correct classloading metadata to reuse the name "vfszip:/Users/kabir/sourcecontrol/jbossas/Branch_5_0/testsuite/output/lib/jaxws-endpoint-servlet.war".
|
How to achieve that if we don't have access to DeploymentUnit? Is it possible to construct it dynamically?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209503#4209503
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209503
17 years, 1 month
[Design of JBoss Web Services] - Dynamic Endpoint Deployment
by richard.opalka＠jboss.com
Kabir Khan wrote:
If you've seen the dev-list discussions yesterday regarding JBAS-6489, I can work around this in AOP, but I have found the cause to be something to do with org.jboss.test.webservice.endpoint.EndpointTestCase. It deploys jaxws-endpoint-servlet.war.
Hot-deploying the war seems to go through the deployer chain twice. Once, when it goes through usual hot-deployment (See Stack1 below), then it does something in the tomcat/service-layer, I guess to deploy the WS endpoint (See Stack2 below).
Now the problem is that the first time it deploys this, it correctly includes a Module attachment with the deploymentunit which links the classloader to a scoped classloading domain called "vfszip:/Users/kabir/sourcecontrol/jbossas/Branch_5_0/testsuite/output/lib/jaxws-endpoint-servlet.war" (See variables1 below). When it deploys the second time, it incorrectly includes a Module attachment with the deploymentunit linking the classloader to the main/non-scoped classloading domain called DefaultDomain. Somehow the new deployment created internally needs to either include the original Module, or the correct classloading metadata to reuse the name "vfszip:/Users/kabir/sourcecontrol/jbossas/Branch_5_0/testsuite/output/lib/jaxws-endpoint-servlet.war". I think this happens around this point of Stack2:
DynamicEndpointDeploymentAspect.create(Deployment) line: 88
DeploymentAspectManagerImpl.deploy(Deployment) line: 115
DeploymentAspectHttpServer.publish(HttpContext, Endpoint) line: 91
Since deployment 2 also passes through the AOPClassLoader deployer and it is getting the wrong information, AOP gets confused about the AOP domains used.
Stack1:
Daemon System Thread [RMI TCP Connection(10)-127.0.0.1] (Suspended (breakpoint at line 58 in VFSClassLoaderDomainRegistry))
VFSClassLoaderDomainRegistry.initMapsForLoader(ClassLoader, Module, ScopedVFSClassLoaderDomain, ClassLoader) line: 58
AOPClassLoaderInitializer.registerLoaders(AOPClassLoaderScopingPolicyWithRegistry, DeploymentUnit) line: 78
AOPClassLoaderInitializer.initializeForUnit(DeploymentUnit) line: 41
AOPClassLoaderDeployer.internalDeploy(DeploymentUnit) line: 65
AOPClassLoaderDeployer(AbstractRealDeployer).deploy(DeploymentUnit) line: 50
DeployerWrapper.deploy(DeploymentUnit) line: 171
DeployersImpl.doDeploy(Deployer, DeploymentUnit) line: 1439
DeployersImpl.doInstallParentFirst(Deployer, DeploymentContext) line: 1157
DeployersImpl.install(ControllerContext, ControllerState, ControllerState) line: 1098
DeploymentControllerContext(AbstractControllerContext).install(ControllerState, ControllerState) line: 348
AbstractKernelController(AbstractController).install(ControllerContext, ControllerState, ControllerState) line: 1598
AbstractKernelController(AbstractController).incrementState(ControllerContext, boolean) line: 934
AbstractKernelController(AbstractController).resolveContexts(ControllerState, ControllerState, boolean) line: 1062
AbstractKernelController(AbstractController).resolveContexts(boolean) line: 984
AbstractKernelController(AbstractController).change(ControllerContext, ControllerState, boolean) line: 822
AbstractKernelController(AbstractController).change(ControllerContext, ControllerState) line: 553
DeployersImpl.process(List, List) line: 781
MainDeployerImpl.process() line: 572
MainDeployer.deploy(URL) line: 812
MainDeployer.redeploy(URL) line: 587
Stack2:
Daemon System Thread [RMI TCP Connection(10)-127.0.0.1] (Suspended (breakpoint at line 58 in VFSClassLoaderDomainRegistry))
VFSClassLoaderDomainRegistry.initMapsForLoader(ClassLoader, Module, ScopedVFSClassLoaderDomain, ClassLoader) line: 58
AOPClassLoaderInitializer.registerLoaders(AOPClassLoaderScopingPolicyWithRegistry, DeploymentUnit) line: 78
AOPClassLoaderInitializer.initializeForUnit(DeploymentUnit) line: 41
AOPClassLoaderDeployer.internalDeploy(DeploymentUnit) line: 65
AOPClassLoaderDeployer(AbstractRealDeployer).deploy(DeploymentUnit) line: 50
DeployerWrapper.deploy(DeploymentUnit) line: 171
DeployersImpl.doDeploy(Deployer, DeploymentUnit) line: 1439
DeployersImpl.doInstallParentFirst(Deployer, DeploymentContext) line: 1157
DeployersImpl.install(ControllerContext, ControllerState, ControllerState) line: 1098
DeploymentControllerContext(AbstractControllerContext).install(ControllerState, ControllerState) line: 348
AbstractKernelController(AbstractController).install(ControllerContext, ControllerState, ControllerState) line: 1598
AbstractKernelController(AbstractController).incrementState(ControllerContext, boolean) line: 934
AbstractKernelController(AbstractController).resolveContexts(ControllerState, ControllerState, boolean) line: 1062
AbstractKernelController(AbstractController).resolveContexts(boolean) line: 984
AbstractKernelController(AbstractController).change(ControllerContext, ControllerState, boolean) line: 822
AbstractKernelController(AbstractController).change(ControllerContext, ControllerState) line: 553
DeployersImpl.process(List, List) line: 781
MainDeployerImpl.deploy(Deployment...) line: 445
DynamicEndpointDeploymentAspect.create(Deployment) line: 88
DeploymentAspectManagerImpl.deploy(Deployment) line: 115
DeploymentAspectHttpServer.publish(HttpContext, Endpoint) line: 91
EndpointImpl.publish(Object) line: 172
EndpointServlet.init(ServletConfig) line: 70
StandardWrapper.loadServlet() line: 1048
StandardWrapper.load() line: 950
StandardContext.loadOnStartup(Container[]) line: 4122
StandardContext.start() line: 4421
TomcatDeployment.performDeployInternal(WebApplication, String, String) line: 315
TomcatDeployment.performDeploy(WebApplication, String) line: 147
TomcatDeployment(AbstractWarDeployment).start(DeploymentUnit, JBossWebMetaData) line: 461
WebModule.startModule() line: 118
WebModule.start() line: 97
NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]
NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39
DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25
Method.invoke(Object, Object...) line: 597
ReflectedDispatcher.invoke(Invocation) line: 157
Invocation.dispatch() line: 96
Invocation.invoke() line: 88
XMBean(AbstractMBeanInvoker).invoke(String, Object[], String[]) line: 264
MBeanServerImpl.invoke(ObjectName, String, Object[], String[]) line: 668
ServiceProxy.invoke(Object, Method, Object[]) line: 206
$Proxy36.start() line: not available
StartStopLifecycleAction.installAction(ServiceControllerContext) line: 42
StartStopLifecycleAction.installAction(ControllerContext) line: 37
StartStopLifecycleAction(SimpleControllerContextAction).simpleInstallAction(T) line: 62
StartStopLifecycleAction(AccessControllerContextAction<S,T>).install(ControllerContext) line: 71
ServiceControllerContextActions(AbstractControllerContextActions).install(ControllerContext, ControllerState, ControllerState) line: 51
ServiceControllerContext(AbstractControllerContext).install(ControllerState, ControllerState) line: 348
ServiceControllerContext.install(ControllerState, ControllerState) line: 286
AbstractKernelController(AbstractController).install(ControllerContext, ControllerState, ControllerState) line: 1598
AbstractKernelController(AbstractController).incrementState(ControllerContext, boolean) line: 934
AbstractKernelController(AbstractController).resolveContexts(ControllerState, ControllerState, boolean) line: 1062
AbstractKernelController(AbstractController).resolveContexts(boolean) line: 984
AbstractKernelController(AbstractController).change(ControllerContext, ControllerState, boolean) line: 822
AbstractKernelController(AbstractController).change(ControllerContext, ControllerState) line: 553
ServiceController.doChange(KernelController, ServiceControllerContext, ControllerState, String) line: 688
ServiceController.start(ObjectName) line: 460
ServiceDeployer.start(ServiceContext) line: 163
ServiceDeployer.deploy(DeploymentUnit, ServiceMetaData) line: 99
ServiceDeployer.deploy(DeploymentUnit, Object) line: 46
ServiceDeployer(AbstractSimpleRealDeployer).internalDeploy(DeploymentUnit) line: 62
ServiceDeployer(AbstractRealDeployer).deploy(DeploymentUnit) line: 50
DeployerWrapper.deploy(DeploymentUnit) line: 171
DeployersImpl.doDeploy(Deployer, DeploymentUnit) line: 1439
DeployersImpl.doInstallParentFirst(Deployer, DeploymentContext) line: 1157
DeployersImpl.doInstallParentFirst(Deployer, DeploymentContext) line: 1178
DeployersImpl.install(ControllerContext, ControllerState, ControllerState) line: 1098
DeploymentControllerContext(AbstractControllerContext).install(ControllerState, ControllerState) line: 348
AbstractKernelController(AbstractController).install(ControllerContext, ControllerState, ControllerState) line: 1598
AbstractKernelController(AbstractController).incrementState(ControllerContext, boolean) line: 934
AbstractKernelController(AbstractController).resolveContexts(ControllerState, ControllerState, boolean) line: 1062
AbstractKernelController(AbstractController).resolveContexts(boolean) line: 984
AbstractKernelController(AbstractController).change(ControllerContext, ControllerState, boolean) line: 822
AbstractKernelController(AbstractController).change(ControllerContext, ControllerState) line: 553
DeployersImpl.process(List, List) line: 781
MainDeployerImpl.process() line: 572
MainDeployer.deploy(URL) line: 812
MainDeployer.redeploy(URL) line: 587
Variables1:
loader BaseClassLoader (id=641)
module VFSDeploymentClassLoaderPolicyModule (id=676)
capabilities CopyOnWriteArrayList (id=677)
classLoader BaseClassLoader (id=641)
classLoadingMetaData ClassLoadingMetaData (id=678)
context DeploymentControllerContext (id=637)
contextName "vfszip:/Users/kabir/sourcecontrol/jbossas/Branch_5_0/testsuite/output/lib/jaxws-endpoint-servlet.war" (id=666)
domain Domain (id=361)
classLoading ClassLoading (id=701)
modules CopyOnWriteArrayList (id=703)
modulesByName ConcurrentHashMap<K,V> (id=704)
name "vfszip:/Users/kabir/sourcecontrol/jbossas/Branch_5_0/testsuite/output/lib/jaxws-endpoint-servlet.war" (id=261)
parentDomainName "DefaultDomain" (id=585)
parentFirst false
excludedRoots VirtualFile[0] (id=679)
name "vfszip:/Users/kabir/sourcecontrol/jbossas/Branch_5_0/testsuite/output/lib/jaxws-endpoint-servlet.war" (id=666)
policy VFSClassLoaderPolicy (id=680)
requirementDependencies null
requirements null
space null
system DefaultClassLoaderSystem (id=389)
unit AbstractVFSDeploymentUnit (id=638)
version Version (id=681)
vfsRoots VirtualFile[2] (id=683)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209486#4209486
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209486
17 years, 1 month
[Design of JBoss jBPM] - Re: email templates
by kukeltje
There was an additional reason I asked if you had more info from Pete. The bpm/b2b/... framework I'm developing on top of jBPM uses Facelets/JSF for the webapp, XForms for complex forms (already nicely integrated with seam contexts etc) ebMS for b2b messaging. Besides this, I need to use facelets with jsf for mail templating (customer requirement, does not want to learn new technology). So in my case it is not a big problem since there always is a webapp (even jsf based). But....out of the blue the customer asked me if it would be possible to use this mail templating in a rich client they have. So I have some payed time to look into this if I can get 'booted'. Pete just has to bootstrap me a little.
GA is July 1st right?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209480#4209480
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209480
17 years, 1 month
[Design of JBoss Identity] - Re: typed interface of identity api
by bdaw
For the first point I agree it could be improved to avoid unnecessary calls. Like I mentioned in the other post (http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209457#4209457) I'm still thinking a bit about how IDs should be handled.
Actually currently in both IdentityStore implementation the IdentityObject name is required to be unique per IdentityObjectType. This makes any IdentityObject uniquely identified by pair of name/type. Translating this into the API language:
- Identity is uniquely identified by its name
- Group is uniquely identified by name/GroupType pair.
Therefore current String ID is mostly only internal IdentityStore information that lets to retrieve such object efficiently (directly - without additional queries). Maybe it would make sense to let use those information in API more directly? Something like:
- associateGroups(GroupType parentType, String, parentName, GroupType childType, String childName)
or use other object to embedd those information (name/type + optionally store internal id) and let construct it without need to fetch anything from the store...
I'm open for suggestions...
For the second issue regarding the role association:
The main problem is to keep in mind that some of IdentityStore implementations won't support roles at all (simple LDAP tree shape is the perfect example). That's why I want to distinguish it in the API. However I'm still thinking about adding switches to RelationshipManager methods to also fetch roles in "findAssociatedXXX()" methods and will probably go this way... need to check if it doesn't make additional complications internally and keeps the API consistent.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209472#4209472
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209472
17 years, 1 month
[Design of JBoss Identity] - Re: User in API, User for business process in companies
by bdaw
The main problem with the design and ids is that the framework provides something like a federation of the identity stores. So it is not only that you can have two different stores with different objects used to serve as the real ID (eg. Hibernate - Long, LDAP - String DN). When one store is not capable to persist all needed identity attributes (LDAP and limited schema for user profile) then such identity need to be synced into default store (hibernate) to keep the rest of the info. Therefore it can be a bit tricky to handle different ID Object types between API and SPI store repository level in an efficient way.
As you mentioned the intention behind the project is to provide same API/model for different JBoss projects. Before alpha1 was pushed and discussion moved into the forums we had some internal discussion between various projects. Pre alpha ID was pure Object and this was one of the concerns rised by JBPM team. As they store id reference to users using generic IDs would require them to support every store implementation separately. That is the main reason why in the Alpha1 API we have IdentityType ID as String.
As I see now the hardest part for the framework and API design is to address well both basic and complex needs without adding too much unnecessary overhead to the first and too much constraints to the second ones ...
I'm still thinking about how to improve the design for the IDs in the current. One of the issues in the SPI level is that IdentityStoreRepository has no way to recognize to which mapped IdentityStore given ID belongs. Currently ID is just a String representation of id from actual store (so String representation of Long for Hibernate store). I'm thinking about encoding internally more information into String ID like:
- Realm name
- Repository id
- IdentityStore id
- Actual internall store id value
Then it would be decoded on the IdentityStoreRepository level and let to handle IDs in a more efficient way.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209457#4209457
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209457
17 years, 1 month