November 2006 - jboss-dev-forums - Jboss List Archives

[Design of JBoss jBPM] - Re: deploying from cvs head to 4.0.4 and mysql 4.1.x job err

by kukeltje

that's what I'm going to try this afternoon. I was also thinking of adding a small post processing class for mysql to transform the bit to tinyint(1) and add semicolumns at the end. That way the file can be used directly. Anyone have any problems with that? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983279#3983279 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3983279

19 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Re: Injection of MBeanServer

by scott.stark＠jboss.org

Why does the cache need the MBeanServer? The existing behavior can be obtained by wrapping a pojo cache(its not pojo if it relies on jmx classes) in an mbean that implements MBeanRegistration. The JMX integration should be a layer independent of the core class. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983273#3983273 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3983273

19 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Injection of MBeanServer

by bstansberry＠jboss.com

I'm a bit concerned that there's no longer any way to inject an MBeanServer into a PojoCache/Cache/TreeCache. In 1.x, the server was injected via the ServiceMBeanSupport's impl of javax.management.MBeanRegistration. In HEAD, that's gone with no replacement. We now rely solely on the internal MBeanServer lookup code in JmxUtil. That lookup code works fine in the AS, since JmxUtil prefers to find the "jboss" MBeanServer. Also works outside the AS if there is only one MBeanServer in the JVM. It's not reliable outside the AS if there is more than one MBeanServer in the JVM. This could be a real problem, because the way JBC now does JMX integration provides no hooks to allow a user to manage the integration themselves -- at least not if they use our factories. E.g. this won't work: MBeanServer weblogicServer = getWebLogicJMXFromSomewhere(); | Configuration config = buildConfigSomehow(); | Cache cache = DefaultCacheFactory.createCache(config, false); | weblogicServer.registerMBean(cache, new ObjectName(...)); // FAIL! Cache is not an mbean At first I thought we could add get/setMBeanServer() to CacheSPI. But that doesn't work for PojoCache, which doesn't extend CacheSPI. Adding get/setMBeanServer() to PojoCache sounds terrible. Another option is to add overloaded methods to CacheFactory and PojoCacheFactory, where the MBeanServer is passed to createCache. The factory can then pass the server into TreeCache and PojoCacheImpl. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983266#3983266 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3983266

19 years, 5 months

1
0
0 / 0

[Design of JBossCache] - Re: Incorrect serialization of PojoCache collection class pr

by bstansberry＠jboss.com

It's too bad there's no obvious way to distinguish the 2 use cases when doing the serialization. 2 use cases being 1) serializing as part of a JBC replication (like in the other forum thread that led to this issue) and 2) other types of serialization like I described above. With the first, I agree, it's easy for the user to get confused and expect some relationship will survive the serialization. Giving them help is not bad. For the second case, if they think that somehow a relationship will survive by magic when a remote cache isn't even involved, well, they're just not thinking at all; I don't feel any strong need to "help" in such a case. Hmm -- instead of throwing an exception, why not log a WARN and then do the writeReplace? The category logging the WARN is the proxy class, so if people write code where they're doing this on purpose and understand what they're doing, they can just limit the proxy class category to ERROR. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983264#3983264 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3983264

19 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: Relative order of deployers to other deployers

by adrian＠jboss.org

Like I said on a different thread, my preference is for each deployer to define its input/output metadata. This will lead to a natural (relative) ordering. The relative order is still required however to define when each step is taken (relative to other deployers that are not in the same chains). e.g. We always classloaders to be created together even if they are different implementations for different deployer chains. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983214#3983214 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3983214

19 years, 5 months

1
0
0 / 0

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

by adrian＠jboss.org

Ok, I'll take a look at what you did when I have time. You probably did it wrong, but that's ok. ;-) Like I said on a different thread (in the POJO forum), the real solution is to provide two different views of the metadata. 1) The particular level that is modifiable, e.g. the AOP instance annotations e.g. (scope key) instance=SomeInstanceId 2) The tree structure that is used at runtime and is read only instance=SomeInstanceId,class=com.acme.Blah,deployment=whatever.jar,etc. this is made up on the particular levels defined in (1) The repository needs to contain both views. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983212#3983212 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3983212

19 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: Are you considering an OSGi based micro kernel ?

by c.vidal

Hey hello Ales :) Thanx for the tip ! I'll have a look. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983201#3983201 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3983201

19 years, 5 months

1
0
0 / 0

[Design of POJO Server] - Re: Are you considering an OSGi based micro kernel ?

by alesj

"c.vidal" wrote : but I can't find any document stating JBoss'position on that matter. | There is a module in Microcontainer, OSGi-int, currently managed by Scott. So you can follow our progress there. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983195#3983195 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3983195

19 years, 5 months

1
0
0 / 0

[Design of EJB 3.0] - Ejb3ClientDeployer handling j2ee14 clients

by scott.stark＠jboss.org

So can we look at handling j2ee14 client deployments in the Ejb3ClientDeployer? Right now its blowing up on such deployments because they have no main class setting. I don't see why we can't default to a jboss main class in such a circumstance and build the env based on the descriptors with no injection. | 00:03:43,684 ERROR [Ejb3ClientDeployer] Error during deployment: jar:file:/home/svn/JBossHead/jboss-head/testsuite/output/lib/app-client.ear!/app-client.jar | org.jboss.deployers.spi.DeploymentException: Could not deploy jar:file:/home/svn/JBossHead/jboss-head/testsuite/output/lib/app-client.ear!/app-client.jar | at org.jboss.ejb3.deployers.Ejb3ClientDeployer.deploy(Ejb3ClientDeployer.java:93) | at org.jboss.ejb3.deployers.Ejb3ClientDeployer.deploy(Ejb3ClientDeployer.java:53) | 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.process(MainDeployerImpl.java:381) | at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:795) | 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.Exception: Main-Class is null | at org.jboss.ejb3.deployers.Ejb3ClientDeployer.getMainClassName(Ejb3ClientDeployer.java:164) | at org.jboss.ejb3.deployers.Ejb3ClientDeployer.deploy(Ejb3ClientDeployer.java:79) | ... 56 more | 00:03:43,688 INFO [Ejb3Deployment] EJB3 deployment time took: 0 | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983179#3983179 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3983179

19 years, 5 months

1
0
0 / 0

[Design of JBoss Portal] - Re: missing groups for role assignments

by bvogt

"julien(a)jboss.com" wrote : Bvogt, | | could you give us a few use case to see what you mean in action ? yes, no problem... Think of a portal which provides different (business) functionality (e.g. applications accessible through the portal via SSO) for different (business ) groups of users (e.g. general manager, sales manager, normal employee, ...). Assuming that the business groups are well defined, granting access to the portal for a new user means just adding it to the proper group. This causes the following enhancements: - definition of a new structural object: portal groups - portal groups (can) have users and roles assigned - dynamic assignment of user roles within the IdentityLoginModule by evaluation of its group memberships. This functionality is currently provided based on a SAP Netweaver Portal for our customer... If I look around I see, that e.g. liferay and jetspeed2 have this feature... Burkhard cf. http://jboss.org/index.html?module=bb&op=viewtopic&t=92487 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3983149#3983149 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3983149

19 years, 5 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 November 2006