Michael McGrady wrote: > Imagine that in order to use Log4J you had to setup JINI because an > interface important to Log4J were in JINI. This problem would not be
So you are complaining that making use of Entry requires you setup Jini? Not true - the reason you must setup Jini is to discover your JavaSpace because there is no other mechanism for that right now. It's not a direct result of including Entry. It's a direct result of running a JavaSpace that wants to do discovery/join. So it seems to me we're not talking architecture at all. We're talking about providing a .jar with all dependencies and providing a non-networked lookup implementation to slot in. And thus I claim you confuse packaging and implementation (physical details) with architecture. > solved by pointing out that you can use JINI without Log4J. And, if > someone said they thought Log4J was conceptual independent of JINI and > should be made so in its interfaces, that would be a good point. It > would not be a retort to say that Log4J would not work in these > conditions without JINI. > > Am I clear? > > Mike > > On Dec 11, 2008, at 7:32 PM, Dominic Cleal wrote: >> >> I have to jump in at this point and ask if you have ever used Jini >> without >> JavaSpaces? Why do you think Jini is somehow dependent upon >> JavaSpaces and >> what's your justification? >> >> It's entirely possible to use all manner of Jini services without any >> need for >> a JavaSpace. Your distributed system doesn't require a JavaSpace to >> be "conceptually" valid. Jini is more than you're making it out to be. > > Michael McGrady > Senior Engineer > Topia Technology, Inc. > 1.253.720.3365 > mmcgr...@topiatechnology.com > > > > >
