9 Replies Latest reply on Dec 3, 2004 10:05 AM by peter neville

    uuid generation

    peter neville Newbie

      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

        • 1. Re: uuid generation
          peter neville Newbie

          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.


          • 2. Re: uuid generation
            Juha Lindfors Master

            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.

            • 3. Re: uuid generation
              peter neville Newbie

              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

              • 4. Re: uuid generation
                peter neville Newbie

                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

                • 5. Re: uuid generation
                  Darran Lofthouse Master

                  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.


                  • 6. Re: uuid generation
                    peter neville Newbie

                    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

                    • 7. Re: uuid generation
                      Scott Stark Master

                      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.

                      • 8. Re: uuid generation
                        peter neville Newbie

                        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?



                        • 9. Re: uuid generation
                          Scott Stark Master

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