January 2007 - jboss-dev-forums - Jboss List Archives

[Design of JBoss jBPM] - Re: new simplified menu structure

by jeffdelong

I agree with Tom with a few comments / additions: On Task list: a common term for "take" is "acquire". So you might name the button that performs this operation "acquire". In some applications users will acquire the task from the tasklist, and the act of acquiring will navigate to the TaskInstance page. On the other hand, you could let the user navigate to the TaskInstance page and then acquire (but this would be a less common way of designing this). When the user acquires a task, you should set the actorId (this is probably obvious), and also start it (this is good for reporting purposes). Having acquired a task from the group task list, the user should be able to release it (set ActorId back to null) on the TaskInstance page, and close the page. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3998387#3998387 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3998387

19 years, 4 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: remove context sensitive menus

by jeffdelong

I agree with Tom. I had problems understanding the left-hand side context menus: No Task Available No Process Available In particular, a submenu says No Definitions, yet I know I have process definitions deployed. I also have a comment on Terminology. We seem to be equating Processes with ProcessDefinitions. This is okay, most users don't like to say processdefinitions, but we must always be clear when dealing with instances that we say ProcessInstances, so that the difference is clear. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3998384#3998384 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3998384

19 years, 4 months

1
0
0 / 0

[Design of AOP on JBoss (Aspects/JBoss)] - Re: Metadata rewrite

by kabir.khan＠jboss.com

This has been commited to head. The only reason I added the KCCA to AOPConstructorJoinPoint was to allow the insertion of the ControllerContext - I'll see if I can do the required work in another place. If not, I need some interface to inject it, but don't particularly care what it is called View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3998377#3998377 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3998377

19 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Metadata merged in head

by kabir.khan＠jboss.com

I have commited Adrian's work on the metadata to head: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=85442&start=10 You will need to update the aop and microcontainer (aop-mc-int, container and kernel) jars View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3998375#3998375 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3998375

19 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: Problem deploying a -beans.xml in a SAR

by kabir.khan＠jboss.com

I get the same error when hot-deploying a .jar with a META-INF/beans.xml from the aop testsuite. (In case you wonder I commented out the aspect from the test): 19:56:12,593 ERROR [BeanMetaDataDeployer] Error during deployment: jboss:id=aop-mc-defaultannotationtest.jar,service=jacc | org.jboss.deployers.spi.DeploymentException: Error deploying: jboss.aop:name=Bean | at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49) | at org.jboss.deployers.plugins.deployers.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:71) | at org.jboss.deployers.plugins.deployers.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:42) | at org.jboss.deployers.plugins.deployers.helpers.AbstractSimpleRealDeployer.deploy(AbstractSimpleRealDeployer.java:53) | at org.jboss.deployers.plugins.deployer.AbstractSimpleDeployer.commitDeploy(AbstractSimpleDeployer.java:52) | at org.jboss.deployers.plugins.deployer.DeployerWrapper.commitDeploy(DeployerWrapper.java:145) | at org.jboss.deployers.plugins.deployment.MainDeployerImpl.commitDeploy(MainDeployerImpl.java:440) | at org.jboss.deployers.plugins.deployment.MainDeployerImpl.commitDeploy(MainDeployerImpl.java:451) | at org.jboss.deployers.plugins.deployment.MainDeployerImpl.commitDeploy(MainDeployerImpl.java:451) | at org.jboss.deployers.plugins.deployment.MainDeployerImpl.process(MainDeployerImpl.java:381) | at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:795) | at org.jboss.deployment.MainDeployer.redeploy(MainDeployer.java:570) | 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) | at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) | at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) | at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) | at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) | at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668) | 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) | at org.jboss.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:266) | 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) | at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) | at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) | at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138) | at org.jboss.mx.server.Invocation.invoke(Invocation.java:90) | at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140) | at org.jboss.mx.server.Invocation.invoke(Invocation.java:90) | at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) | at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668) | at org.jboss.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:179) | 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) | at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) | at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) | at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) | at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) | at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668) | at org.jboss.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:816) | at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:417) | 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) | at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294) | at sun.rmi.transport.Transport$1.run(Transport.java:153) | at java.security.AccessController.doPrivileged(Native Method) | at sun.rmi.transport.Transport.serviceCall(Transport.java:149) | at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466) | at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707) | at java.lang.Thread.run(Thread.java:595) | Caused by: java.lang.IllegalStateException: jboss.aop:name=Bean is already installed. | at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:249) | at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:177) | at org.jboss.deployers.plugins.deployers.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:67) | ... 59 more | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3998371#3998371 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3998371

19 years, 4 months

1
0
0 / 0

[Design of JBossCache] - PojoCache uses a special node factory

by bstansberry＠jboss.com

Quick brain dump... I think PojoCache has some issue with its _JBossInternal_ node(s) -- things like data versioning changes with optimistic locking, potential lock contention due to the large number of child nodes, etc. One thing I noticed is the Configuration.getRuntimeConfig() object now exposes the NodeFactory as a property. This means PojoCache can set the NodeFactory to something specific to PojoCache. This opens up the possibility of having a specialized factory create specialized nodes for _JBossInternal_. For example, one whose data version is always 0, or that has a more complex structure for holding child nodes to avoid lock conflicts, etc. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3998368#3998368 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3998368

19 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: remoting various services

by bill.burke＠jboss.com

Well, AOPRemoting sits on top of JBoss Remoting...If we use AOP Remoting we will be able to cluster(request failover) and secure JNDI fairly easily. The question is, what module should this code live? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3998348#3998348 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3998348

19 years, 4 months

1
0
0 / 0

[Design of POJO Server] - Re: remoting various services

by scott.stark＠jboss.org

The basic plan was to align all transports on remoting 2.0: http://jira.jboss.com/jira/browse/JBAS-3925 which includes updating the NamingService. http://jira.jboss.com/jira/browse/JBAS-3927 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3998344#3998344 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3998344

19 years, 4 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Aspect integration to bootstrap classes

by scott.stark＠jboss.org

The question is should be drop the jboss-aop-mc-int-boot.jar and allow for use of aspects in the bootstrap-beans.xml. What I'm needing to do is the equivalent of adding these aspects/pointcuts: | <aspect name="persist" | class="org.jboss.profileservice.aop.PersistAdvice"/> | <aspect name="mainDeployer" | class="org.jboss.profileservice.aop.MainDeployerAdvice"/> | <bind pointcut="execution(* | $instanceof{org.jboss.deployers.spi.deployment.MainDeployer}->process(..))"> | <advice name="process" aspect="mainDeployer"/> | </bind> | <bind pointcut="execution(* | $instanceof{org.jboss.managed.api.ManagedProperty}->setValue(..))"> | <advice name="setValue" aspect="persist"/> | </bind> | Are there aop/mc integration constructs that already allow for this? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3998338#3998338 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3998338

19 years, 4 months

1
0
0 / 0

[Design of POJO Server] - remoting various services

by bill.burke＠jboss.com

What are we using to remote services deployed? I want to refactor JNDI so that it uses AOP Remoting (what EJB3 uses). Since JBoss Remoting is URL based, there is no need for two sockets now for JNDI (stub/rmi). Also if the service is layered. But... is there a different plan to remote services? thx View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3998332#3998332 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3998332

19 years, 4 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 January 2007