uuid generation

[p_nevilleuk]

Hi,
I've been looking into the uuid-key-generator.sar as I need to create a uuid. Unfortunately, it does not seem to implement the standard as described in DCE 1.1 RPC (and draft-leach-uuids-guids-01.txt).

I see that j2se 1.5 now has java.util.UUID and this seems close to the spec, but does not have a way of creating a UUID based on the MAC address.

I have found one that seems to be okay (http://www.doomdark.org/doomdark/proj/jug/index.html), but would prefer to use one that is part of JBOSS or j2se.

Are there any plans to update it?

Thanks in advance,
Peter

[p_nevilleuk]

Within the EJB specification there are a number of programming restrictions, one of the restrictions is: -

The enterprise bean must not attempt to load a native library.

As the component you are trying to use makes use of JNI it should not be used directly within an EJB component. By wrapping the component with an MBean this restriction no longer applies.

[juha]

To get MAC address in Java you need to include JNI code (at least in the older JDK's), so for that reason the doomdark implementation will not be making it into the distribution.

However, nothing stops you from wrapping it as an MBean and deploying it to the JBoss app server, if your application requires it.

[p_nevilleuk]

Thanks for your response Juha. I understand about the native code issue, but my greatest grievance is with the generator in jboss and j2se 1.5 not conforming to standards (or at least the DCE 1.1 RPC standard).

I could always pass the MAC address to a suitable API (obtained manually, natively or via executing ipconfig etc at Runtime).

Like you say, I can always replace with my own but again I would prefer jboss to use a standard generator.

Thanks,
Peter

[p_nevilleuk]

Juha,
Regarding wrapping it as an MBean. I am interested in this approach, but I am not entirely sure what the reason for doing so is.
I can see that the MBean would provide a service to all apps running on the server, but this could be achieved by adding it to the ear. Also, the doomdark api does not require any persistence so does this make it less MBean appropriate?
Are there any other benefits of a UUID MBean?

Thanks,
Peter

[darranl]

Within the EJB specification there are a number of programming restrictions, one of the restrictions is: -

The enterprise bean must not attempt to load a native library.

As the component you are trying to use makes use of JNI it should not be used directly within an EJB component. By wrapping the component with an MBean this restriction no longer applies.

[p_nevilleuk]

Appreciate answers to the following if possible:

What about if a POJO used JNI and the EJB called this - is this acceptable?

How is the MBean accessed? Do you normally store in on JNDI or access it using RMIAdaptor?

I notice that the jboss admin guide uses a NonSerializableFactory to bind it. I thought this was not acceptable (http://www.jboss.org/wiki/Wiki.jsp?page=HowDoIGetRemoteAccessToMyMBean)

I initially need local access, but remote access may be required later.

Which type is most suitable?

Thanks

[starksm64]

Not acceptable in whose eyes, ejb spec, god, country?

For the most part the ejb spec restrictions are meaningless unless you are running with a security manager and have configured the server to restrict application deployments from access to the spec stated operations. Other containers run with a security manager by default so using a pojo in a seperate jar that can be assigned the required security permissions is the usual route of providing restricted functionality to the ejb.

Exposing an interface in jndi via the NonSerializableFactory does not prevent access via the detached invoker mechanism via the same or a different interface as well.

[p_nevilleuk]

Can you exaplain then the following paragraph taken from the wiki

NonSerializableFactory

NO!!!

This seems to be a common misunderstanding. The NonSerializableFactory takes objects that are not java.io.Serializable (and hence can't be bound into jndi by spec) and creates an indirection such that they can be bound. The object is still not serializable and in no way will it be available on a remote machine. The indirected object can be accessed inside the same JVM as where it is bound.

Even if it was Serializable you would get a copy of the object not remote access, see above.

Question: Why do people

Is this information incorrect or does it relate to a different issue?

[starksm64]

The information is correct. What is your question about it as I don't see how it intersects this thread.