[Design of POJO Server] - Re: Missing org.jnp.server.NamingServer_Stub
by dimitris@jboss.org
I've tryied adding org.jnp.server.NamingServer.class in jnp-client.jar but the error remaims the same:
| Caused by: java.lang.ClassNotFoundException: org.jnp.server.NamingServer_Stub (no security manager: RMI class loader disabled)
| at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:371)
| at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:165)
| at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:620)
| at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:247)
| at sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:197)
| at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1544)
| at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1466)
| at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1699)
| at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
| at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
| at java.rmi.MarshalledObject.get(MarshalledObject.java:135)
| at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:290)
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191227#4191227
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191227
17 years, 4 months
[Design of JBoss jBPM] - jBPM 3.3 GA feedback in the user forum
by kukeltje
Guys,
There is some feedback coming in in the user forum regarding jBPM 3.3 GA. Basically it focuses around the installer and to some extend related to the docs. Some remarks:
- The 3.3 release is not in line with the getting started docs.
- People expect to be able to use jBPM out of the box when the installer has run.
- - Database correctly configured
- - Database populated
- How to install on a headless server
The first item is already in Jira as Thomas reopened https://jira.jboss.org/jira/browse/JBPM-1727.
Regarding the database, I tend to agree with the users. It is not really visible in any warning or doc (at least not that I found). This could be partly solved by the previous item, but in my opinion, we should provide a screen in the installer that asks for username, password and e.g. database url and preconfigure that and populate the database (as is the case with HSQLDB, but not done via sql scripts
An option for a headless install is another one. The fact that the automatic install script can be used for this with e.g. just changing the install path in the generated file and how to use it should be documented.
I'll make Jira issues of these in the weekend, but thought I'd initially share them here.
Stay tuned for (hopefully not) more
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191218#4191218
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191218
17 years, 4 months
[Design the new POJO MicroContainer] - Is ParameterizedClassInfo serialization broken
by alesj
Looking at ParameterizedClassInfo, I have a few doubts about its serialization.
| public class ParameterizedClassInfo extends DelegateClassInfo
| {
| /** The serialVersionUID */
| private static final long serialVersionUID = 2;
|
| /** The factory */
| protected transient IntrospectionTypeInfoFactoryImpl factory;
|
| /** The parameterized type */
| transient ParameterizedType parameterizedType;
|
| /** The owner type */
| private TypeInfo ownerType = ClassInfoImpl.UNKNOWN_TYPE;
|
| /** The type arguments */
| private TypeInfo[] typeArguments = ClassInfoImpl.UNKNOWN_TYPES;
|
| /** The component type */
| private transient TypeInfo componentType = ClassInfoImpl.UNKNOWN_TYPE;
|
| /** The key type */
| private transient TypeInfo keyType = ClassInfoImpl.UNKNOWN_TYPE;
|
| /** The key type */
| private transient TypeInfo valueType = ClassInfoImpl.UNKNOWN_TYPE;
|
| /**
| * Create a new ParameterizedClassInfo.
| *
| * @param factory the factory
| * @param delegate the raw array info
| * @param parameterizedType the parameterized type
| */
| public ParameterizedClassInfo(IntrospectionTypeInfoFactoryImpl factory, ClassInfo delegate, ParameterizedType parameterizedType)
| {
| super(delegate);
| this.factory = factory;
| this.delegate = delegate;
| this.parameterizedType = parameterizedType;
| }
|
| public TypeInfoFactory getTypeInfoFactory()
| {
| return factory;
| }
|
| @Override
| public TypeInfo[] getActualTypeArguments()
| {
| if (typeArguments == ClassInfoImpl.UNKNOWN_TYPES)
| typeArguments = factory.getActualTypeArguments(this);
| return typeArguments;
| }
|
| @Override
| public TypeInfo getOwnerType()
| {
| if (ownerType == ClassInfoImpl.UNKNOWN_TYPE)
| ownerType = factory.getOwnerType(this);
| return ownerType;
| }
|
| @Override
| public ClassInfo getRawType()
| {
| return delegate;
| }
|
| @Override
| public TypeInfo getComponentType()
| {
| if (componentType == ClassInfoImpl.UNKNOWN_TYPE)
| componentType = factory.getComponentType(this);
| return componentType;
| }
|
| @Override
| public TypeInfo getKeyType()
| {
| if (keyType == ClassInfoImpl.UNKNOWN_TYPE);
| keyType = factory.getKeyType(this);
| return keyType;
| }
|
| @Override
| public TypeInfo getValueType()
| {
| if (valueType == ClassInfoImpl.UNKNOWN_TYPE)
| valueType = factory.getValueType(this);
| return valueType;
| }
|
After serialization, componentType, keyType, valueType are all gonna be null == not ClassInfoImpl.UNKNOWN_TYPE,
hence null would be returned.
Even if they were equal to ClassInfoImpl.UNKNOWN_TYPE,
NPE would be thrown due to factory being null.
Is this expected behavior (the first, not NPE :-))?
ps: just saw that there is ';' at the end of 'if' in getKeyType :-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191191#4191191
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191191
17 years, 4 months