hmmm it is a bit trickier than that. Some of the parts of RMI RELY on the exception being thrown (looking for a skeleton for example). So we really need to throw that exception. The bottom line is that I guess the best we can do is wait for the end of a deployment.
That makes the deployer code tied to the system libraries but it also forces me to implement the full tracking I always wanted to do ... hmmmmm... I might try it. If I can do it today, it would really be powerful. The feature: Compute the set of dependent object classes (transitive closure of dependents in working man terms) and cycle them as one as the classes change. This avoids the "I changed B but A that references B is invalid so it is broken" "How do we fix this, well we cycle the whole island". marcf |-----Original Message----- |From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] |Sent: Tuesday, February 26, 2002 8:20 AM |To: marc fleury |Cc: David Jencks; Jason Dillon; Jboss-Development @ Lists . Sourceforge |. Net |Subject: Re: [JBoss-dev] Auto-resolving dependencies/deployment | | |Cool idea to solve the class loading dependency, but I think we still |need explicit dependency declarations. The problem I still see is the |need to have some services started (i.e. initialized) before others |(e.g. db driver setup before a ejb can deploy). | |Oh, I just thought of another problem. In my code, I try to load the |classes that are specified in the deployment descriptor. What happens |if the user makes a typo and I try to load something like |java.lang.OObject. Will deployment hang forever? | |-dain | |marc fleury wrote: | |> |I don't think this is a problem. The client is most likely a |thread started |> |by noticing a new package. Anyway, I think we need anyway a list of |> |"waiting deployments" -- partly deployed stuff that is waiting. Now we |> |> Yes, I am afraid of the verbosity of it. |> |> |have mbeans that can be waiting for mbeans, with marc's idea we'd have |> |classes waiting for classes also. If we can look at the list and say " |> |> not classes, deploymentInfo level (meaning anything entering the system). |> This is deployments waiting on deployments (through classes waiting on |> classes). Then mapping to the MBean is done as well. We will collect the |> dependency at the class level. |> |> |there's a problem, kill this guy" or "hmmm, I see I forgot to deploy |> |package X" I think it will be fine without any timeouts. |> |> well the time out is OK, no big deal. The only issue is do you |want to drop |> a package and then another and they are picked in different cycles and it |> still works, but if you FORGET to drop the package, I would want to say |> "CLASS NOT FOUND" so you know you forgot, hence the timeout being useful |> (imho). Small point. |> |> marcf |> |> |> _______________________________________________ |> Jboss-development mailing list |> [EMAIL PROTECTED] |> https://lists.sourceforge.net/lists/listinfo/jboss-development |> | _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
