Discussions

News: Jakarta HiveMind 1.0-rc-1 Released

  1. Jakarta HiveMind 1.0-rc-1 Released (29 messages)

    The first release candidate for HiveMind 1.0 is now available. The controversial Simple Data Language has been removed; HiveMind configuration is back to pure XML, and efforts have been made to streamline the content of the XML (Defaults! Defaults! Defaults! as Marc Fleury would say).

    A number of bugs have been fixed -- many in the form of submitted patches (thanks Stefan, James, Naresh, Johan etc.). The documentation has been greatly improved.

    HiveMind is available as a combined binary/source release.

    Threaded Messages (29)

  2. My faviroite IoC[ Go to top ]

    is HiveMind.

    .V
  3. Dependency[ Go to top ]

    HiveMind like all other IoC/DI tools speak whole time about flexibility and independence. It's little bit funny for me, because all code which is build on top of this framework is then flexible and POJO and .... but depends on specific framework.
    Why are we inventing new:
    - registries when we have JNDI?
    - database access when we have JDBC?
    - transaction control when we have JTA?
    - message passing when we have JMS?

    Isn't problem inside specifications or service implementations?
    Why shouldn't we improve basic services?

    And then we can with some configuration tool choose specific impelementation of JNDI (in-memory, LDAP, DNS, ...) or JMS (lightweight, transactional, ...).

    From little bit management perspective is it IoC framework really so gool that I can use it for commercial projects with 1000s ManDays which should last longer than 2 years?
  4. Dependency[ Go to top ]

    HiveMind like all other IoC/DI tools speak whole time about flexibility and independence. It's little bit funny for me, because all code which is build on top of this framework is then flexible and POJO and .... but depends on specific framework.Why are we inventing new:- registries when we have JNDI?- database access when we have JDBC?- transaction control when we have JTA?- message passing when we have JMS?Isn't problem inside specifications or service implementations?Why shouldn't we improve basic services?And then we can with some configuration tool choose specific impelementation of JNDI (in-memory, LDAP, DNS, ...) or JMS (lightweight, transactional, ...).From little bit management perspective is it IoC framework really so gool that I can use it for commercial projects with 1000s ManDays which should last longer than 2 years?
    There's a fundamental difference between a Registry, like those backing JNDI APIs, and an IoC container. It's the difference between pull and push. With a Registry a component has to go and look up it's dependencies, thus being tied to JNDI APIs for lookup. With IoC your component will have its dependencies supplied to it before you start using it, and you don't have to know how it happened.

    For the rest of it, no-one's suggesting we replace JTA, JDBC, JMS, etc... Some frameworks, like Spring (and maybe Hivemind, don't know yet), provide wrappers over these lower-level APIs to make them easier to use. You don't have to use these wrappers to get the advantage of IoC though.
  5. Dependency[ Go to top ]

    What's wrong with:

    private MyClass myVariable=(MyClass) Jndi.lookup("aha");

    maybe in near future with 1.5 annotations:

    @lookup("aha") private MyClass myVariable;

    and to setup Jndi in some configuration file as in-memory container with predefined values. I understand IoC but I can't understand real advantage when I can produce similar things with clean pure Java code using standard services.
  6. Dependency[ Go to top ]

    What's wrong with:

    private MyClass myVariable=(MyClass) Jndi.lookup("aha");
    1. Now you can only use this component in a container where "aha" is reserved universally, making "aha" an especially bad choice... perhaps "org.mycompany.mycomponent.aha" would be a better choice but even then, what happens when you want to reuse the _same_ component twice in the same container but you'd like to put a different implementation of MyClass in each?

    2. You're tied to JNDI. This means that if you want a provider other than the ones you can download, you need to write it yourself.

    3. Testing is not pretty, compare the following:

    public void testMyComponent() {
        Object oldMyClass = Jndi.lookup("aha");
        Jndi.bind("aha", new MockMyClass());
        MyComponent myComponent = new MyComponent();
        .... assert some stuff ...
        Jndi.bind("aha", oldMyClass); // so that you don't interfer with any other tests
    }

    vs.

    public void testMyComponent() {
        MyComponent myComponent = new MyComponent(new MockMyClass());
        ... assert some stuff ...
    }
  7. Yes, it is very necessary.[ Go to top ]

    What's wrong with:private MyClass myVariable=(MyClass) Jndi.lookup("aha");maybe in near future with 1.5 annotations:@lookup("aha") private MyClass myVariable;and to setup Jndi in some configuration file as in-memory container with predefined values. I understand IoC but I can't understand real advantage when I can produce similar things with clean pure Java code using standard services.
    Lots.

    Where's your exception handling if the JNDI fails? How do you simulate failure in your unit test suite?

    Why are you doing the JNDI lookup when you instantiate your class, even if you never actually invoke anything on it?

    What happens when the JNDI name changes?

    What if you need to use one JNDI name in testing, and a different one in production?

    Dont't you think going through a static method is problematic? Very procedural. Does the Jndi class cache lookups? For how long? How is it cleared?

    Why are you tied to JNDI when you will likely want to use something else tomorrow?

    Why should your code break just because you've changed your mind about any of these things?
  8. Yes, it is very necessary.[ Go to top ]

    Look for my original questions.
    Where's your exception handling if the JNDI fails?
    Wrong interface design of JNDI - fix it?
    How do you simulate failure in your unit test suite?
    JNDI configuration.
    Why are you doing the JNDI lookup when you instantiate your class, even if you never actually invoke anything on it?
    Should it be proxy, AOP rules. Look for my second example with annotation.
    What happens when the JNDI name changes?
    What if you need to use one JNDI name in testing, and a different one in production?
    Wrong JNDI interface? Should JNDI code first look into some translation/property file?
    Does the Jndi class cache lookups? For how long? How is it cleared?
    Why are you tied to JNDI when you will likely want to use something else tomorrow?
    Better to stick with JNDI then with Hive/Spring. I don't care about JNDI service. I'm not against configuring it from XML file but with standard JNDI interface.
    Why should your code break just because you've changed your mind about any of these things?
    Because for complex project IoC bring too mutch rules between object declarations. I'm not against IoC, however isn't Spring, Hive, ... going too far?
    Look for my original questions.
  9. Yes, it is very necessary.[ Go to top ]

    You are right! It is absolutely unnesessary for you to use any IOC framework if you happy with existing way of doing things.
    Although i do not understand why do you seek any approvement for your decision. Anyway, if you need it, here you go! I give you permission not to use IOC frameworks.
    And now let us use them, cause we (not you) need them.
  10. Yes, it is very necessary.[ Go to top ]

    Lots.Where's your exception handling if the JNDI fails? How do you simulate failure in your unit test suite?Why are you doing the JNDI lookup when you instantiate your class, even if you never actually invoke anything on it?What happens when the JNDI name changes?What if you need to use one JNDI name in testing, and a different one in production?Dont't you think going through a static method is problematic? Very procedural. Does the Jndi class cache lookups? For how long? How is it cleared?Why are you tied to JNDI when you will likely want to use something else tomorrow?Why should your code break just because you've changed your mind about any of these things?
    First, I find the amount of religious devotion that something like push configuration receives frankly quite astonishing. I think it's nice and
    clever, but it does not really make me "see the light". In recent large projects (1000nds classes, hundreds of JSP, millions of users) one thing you could really see was a clear tradeoff between maintainability vs. flexibility.

    Generally the "new" technologies like push config or AOP place more emphasis on flexibility than on maintainability. Sure some of you would disagree, because they believe there system is cleanly build and not dependent on the framework.
    I am however quite sure that these kinds of approaches easily create an dependency where there is no appaarent technical dependency. For example AOP code can easily rely on the implementation of what is advised on, or code can depend on some expected behaviour of what is configured in, even if there is no actual contract in place. I can come up with hundred of examples, but I try a simple one.

    Consider a class that needs to do some JDBC. Very likely you will want to pass something like a datasource in the container configuration. Unfortuantely datasources can be connection pools, they can supply a single connection, they can be robust (keep going through a database outage) or not. So you have several ways of going about it:

    (1) You can use an API for wrapping any Datasource in a RobustDataSource. That makes you dependent on some "plumbing" interface or class which you might want to avoid.
    (2) You use a class the framework delivers, in which case you are dependent on the framework
    (3) you program defensively

    Generally and technically you will often do (1). I actually think that

    DataSource = new RobustDataSource((DataSource)resultOfSomeJNDILookup)

    inside a piece of code might be better than configuring it in using a container configuration file because the dependency is explicit. I actually want it to be just that. Code can be damn hard to read when maintaining or looking for bugs someone planted who has long left a project.
  11. Keeping a closed mind[ Go to top ]

    Nobody can open your mind to a good idea but yourself. We (the proponents of, and developers of, lightweight container solutions) are not here to be salesmen, we're here to get work done on our projects, and to share the wealth with others.

    Individually and collectively, we've seen a large amount of code in a large number of real world deployed projects. We've all seen the anti-patterns manifest in people's code, often our own.

    Yes, if you can rigorously enforce coding standards and have a strong, quick-minded, well communicating team the need for these types of solutions diminishes somewhat. I've worked in a large number of organizations with generally very high functioning teams ... and the anti-patterns sneak in anyway. Rushed bug fixes. Smart people with less experience. Rotating developers. Whatever the reason, and there's always a reason, corners get cut. Coding directly to "the metal" (that is, the J2EE APIs) works great in demos, or in lone-developer projects ... but doesn't scale to real world projects and real world teams.

    Yes, you will build functioning apps, and you will deploy them and even maintain them. But without adopting some form of higher level organization, you will always be expending too much effort at each stage.

    I also am astonished by the statement ... place more emphasis on flexibility than on maintainability. The entire point of point of the lightweight container approach is to enhance testability and maintainability.

    I've been writing code professionally unit tests in different languages for 18 years. Unit testing is not a fad for me; I've been unit- and integration- testing since long before I new the right terms for it. Even so, I've been going through a renaissance with Tapestry and HiveMind in terms of testing ... the LWC approach makes it <em>so much more</em> practical to fully test my code ... and this is extending my reach, in terms of the functionality I can deliver in these frameworks.

    Rod, Me, The Spring Team, the Pico Team, The Avalon Team ... we've all tried both approaches and found the heavyweight approach lacking. We've all searched for or created a better alternative and we've all reaped the benefits. So it's a bit grating that you dismiss our side of the argument without even trying to get your feet wet. We've been there, we've done that ... but we've moved on.
  12. Dependency[ Go to top ]

    HiveMind, and the other containers, aren't specifically about replacing JNDI, JDBC, etc. They're about replacing the ugly, fragile, repetitive, boring code between your application specific code and whatever backend or third-party you want to tie into.

    Virtually no Java code you write when building HiveMind applications will import anything from HiveMind. That's about 99% of the cases. There's one or two optional lifecycle interfaces and a couple of optional event interfaces.

    A similar statement can be made for Spring.

    The HiveMind plumbing is inside the HiveMind module deployment descriptors. That code is heavily tested and completely thread safe ... are you sure the same is true for your application?

    HiveMind is about making the simplest choice the correct choice. Late binding and lazy object creation is a correct choice, but requires a lot of plumbing. You can do it manually (but that's a lot of mind-numbingly boring code to write), you might be able to do it with clever use of XDoclet ... or you can use HiveMind and get it for free. You give it an interface, and a POJO implementing the interface and it creates all the code that's needed.
  13. Dependency[ Go to top ]

    Howard, could you please elaborate more on what differentiates HiveMind from lets say Pico?
    From what I have seen it looks like in case of Pico I would code an adapter, and HiveMind has number of predefined useful factories like MethodInterceptor factory, so they could be just configuredÂ…
    Is it cglib/proxy based? Could I use my favorite trick (see http://theserverside.com/news/thread.tss?thread_id=28323#135814 ) easily with HiveMind?
  14. HiveMind, Pico[ Go to top ]

    I'm not very familiar with Pico. It's actually a whole set of tiny containers and uses constructor injection (HiveMind does constructor injection too, though I prefer setter injection). Pico does more work in terms of automatically wiring your objects together, though I'm at a loss as to what it does when multiple objects implement the same interface (i think that's when you go to NanoContainer instead). The Pico guys dislike XML and do everything they can to avoid any of it.

    Another major difference is that HiveMind mandates that all services have an interface and Pico does not. HiveMind builds lots of proxies and interceptors around the interface (these are generated at runtime using Javassist).

    I think your trick would become an interceptor. It could instrument each method invocation to do the necessary setup, teardown and exception handling. Its very easy to build JDK Proxy based interceptors (documentation on the HiveMind web site), and slightly more work to build Javassist interceptors.
  15. Dependency[ Go to top ]

    <quote>HiveMind like all other IoC/DI tools speak whole time about flexibility and independence. It's little bit funny for me, because all code which is build on top of this framework is then flexible and POJO and .... but depends on specific framework.</quote>
    Absolutely not. I would imagine that most of the business objects in a HiveMind applications would look a whole lot like business objects in a Spring application, and have zero dependency on HiveMind. The whole point of such frameworks is to minimize dependencies, and they succeed to a remarkable extent. Of course this is different for class library-style framework features, such as Spring's DAO abstraction (and no doubt some HiveMind APIs), but users only need to use them if they feel that they provide value.
  16. Dependency[ Go to top ]

    HiveMind like all other IoC/DI tools speak whole time about flexibility and independence. It's little bit funny for me, because all code which is build on top of this framework is then flexible and POJO and .... but depends on specific framework.Why are we inventing new:- registries when we have JNDI?- database access when we have JDBC?- transaction control when we have JTA?- message passing when we have JMS?Isn't problem inside specifications or service implementations?Why shouldn't we improve basic services?And then we can with some configuration tool choose specific impelementation of JNDI (in-memory, LDAP, DNS, ...) or JMS (lightweight, transactional, ...).From little bit management perspective is it IoC framework really so gool that I can use it for commercial projects with 1000s ManDays which should last longer than 2 years?
    I have to agree. Why are we stressing every day more and more about anything-independence? First we came with API stacking (EJB over RMI, Object Persitence Mapping over RDBMS, etc.), now we are comming with concept stacking (AOP over OOP) and it seens we are searching the extremme. I can see no magic anywhere around. We are getting more and more XML over Java Code, tags over commands, declarative over procedural, complex over simpler. Who will pay the cost of learning all the stuff, coding xml, running AOP compilers,... when we need only a functional solution to a conceptual problem?
    Should not the simpler solutions be the best all the time?
  17. Dependency[ Go to top ]

    Look, if you don't like what the IoC people are selling, don't buy it. I have seen IoC approaches greatly help systems I've designed, simplifying a great deal of code and removing a lot of unnecessary dependencies that made refactoring or enhancements much more difficult than they had to be. In short, IoC is getting a lot of attention because for a lot of people, it is solving some very common problems in a very elegant fashion. If you don't see that, fine, but a lot of others do. And this isn't some trendy fashion kind of thing; it provides direct benefits. Perhaps you should sit down and play around with something like HiveMind or Spring and see for yourself? Sometimes the ways in which a tool can help aren't immediately apparent and nothing short of direct experience will help explain.
  18. HiveMind vs Spring[ Go to top ]

    I really like the whole IoC thing, and being able to run things outside of any container (EJB or Servlet). I have used Spring for wiring up DAOs with DataSources and found it quite handy. Can someone with experience in both give an opinion on how the two stack up? I'm only familiar with Spring at a basic level, and am not familiar with HiveMind at all.
  19. HiveMind vs Spring[ Go to top ]

    In terms of vertical integrations, Spring has a larger team and a big head start.

    Rod and I have discussed better interaction between the two.

    HiveMind has support for Spring; you can tell it about a Spring BeanContext and it will expose beans within the bean context as HiveMind services. I have some ideas to make this better and easier. Currently, you can often use "service:MyService" to reference a HiveMind service; you will shortly be able to use "spring:MyBean" to reference a Spring bean directly (not as a HiveMind service).

    You might want to search around my blog (http://howardlewisship.com/blog) for a lot of notes on these and related subjects.
  20. Now, if I had posted this (a non-final release), Dion would have quashed it. Instead, it's coming directly from him. Fortunately, a final release is no more than a couple of weeks off.
  21. Jakarta HiveMind 1.0-rc-1 Released[ Go to top ]

    Congratulations to Howard and team. I look forward to taking a closer look at HiveMind.

    Rgds
    Rod
  22. Jakarta HiveMind 1.0-rc-1 Released[ Go to top ]

    Nice to see HiveMind back in XML configuration.

    I went though HiveMind earlier and one of the toughest thing i faced in Hivemind is the Configuration. Out of the container testing is one aspect, where as i want to see somebody really generate the service collaborations for me.

    For instance if I have a java domain model and say,a swing client, then i want somebody to generate the session beans and communication stuffs for me. I am not very sure whether HiveMind can serve this requirement. The HiveMind documentation does not provide enough examples on EJB proxies. I think the author will add few good EJB examples other than the calculator, with some custom interceptors.

    Writing custom interceptors are also a bit difficult at the moment.
     
    RV
  23. Jakarta HiveMind 1.0-rc-1 Released[ Go to top ]

    Nice to see HiveMind back in XML configuration.

    I went though HiveMind earlier and one of the toughest thing i faced in Hivemind is the Configuration. Out of the container testing is one aspect, where as i want to see somebody really generate the service collaborations for me.

    For instance if I have a java domain model and say,a swing client, then i want somebody to generate the session beans and communication stuffs for me. I am not very sure whether HiveMind can serve this requirement. The HiveMind documentation does not provide enough examples on EJB proxies. I think the author will add few good EJB examples other than the calculator, with some custom interceptors.

    Writing custom interceptors are also a bit diffcult at the moment.
     
    RV
  24. Nice to see HiveMind back in XML configuration. I went though HiveMind earlier and one of the toughest thing i faced in Hivemind is the Configuration. Out of the container testing is one aspect, where as i want to see somebody really generate the service collaborations for me. For instance if I have a java domain model and say,a swing client, then i want somebody to generate the session beans and communication stuffs for me. I am not very sure whether HiveMind can serve this requirement. The HiveMind documentation does not provide enough examples on EJB proxies. I think the author will add few good EJB examples other than the calculator, with some custom interceptors. Writing custom interceptors are also a bit diffcult at the moment. RV
    The docs could use a bit on accessing stateless session beans and spring beans.

    Did you look at the "example code" tab? There's now a documented example of building a simplified LoggingInterceptor using JDK proxies ... in maybe 30 lines of code.
  25. Jakarta HiveMind 1.0-rc-1 Released[ Go to top ]

    Congrats Howard,

    I hope to find some time soon to have a look at Hivemind!

    cheers,

    Alef
  26. EJB 3 Overlap?[ Go to top ]

    Not that this is a bad thing, but is there a certain amount of overlap w/EJB3 and HiveMind, partincularly in the dependency injection area? Granted some of the specifics are TBD (eg. how to hide JNDI lookups from the developer), but employing a bit of imagination... What kinds of things could I do w/HiveMind that are not within the out-of-the-box domain of EJB3?

    Trying to understand where HiveMind fits in the constellation of frameworks; what problems it solves, etc.

    Thanks
  27. EJB 3 Overlap?[ Go to top ]

    IMO the biggest advantage of using HiveMind (or another micro-container) over EJB 3 is that you don't have to install a massive bundle but only the services (apis) you need. This give you choice ie in your persistence api and keeps your appllication small if you wamt to host it at an ISP (or bring it to the client-side). But most important it flattens the learning curve and is only complex if you need complexity.

    HiveMind has (as the only micro-container I know) an equivalent to Eclipse extension-points, which can help a lot in flexible designs. Hivemind is from the ground up made around modules which only have to be in the classpath and than find each other - much like eclipse plugins.

    On the other hand I would certainly use EJB if I needed clustering in the middle-tier. I also like the EJB 3 annotations style, because you finally get rid of the extra xml files.
  28. EJB 3 Overlap?[ Go to top ]

    I am sure you can design EJB 3 conainer as Eclipse too, if you found this design good for you. Any alternatyve for EJB or EJB wrapper is useless as framework without service implementations. It is very trivial to load classes or to wrapp services, student can to it himself at home, It is more interesting to know about services HiveMind provides.
  29. Jakarta HiveMind 1.0-rc-1 Released[ Go to top ]

    1. Downloaded hivemind-1.0-rc-1.zip
    2. Tried to run ant from [Hivemind Root]\examples to build examples
       found a list of errors like:
     
    "[Hivemind Root]\hivebuild\dependency.xml:79: Warning: Could not find f
    ile [Hivemind Root]\ext-package\lib\geronimo-spec-ejb-1.0-M1.jar to copy"

    "[Hivemind Root]\hivebuild\dependency.xml:79: Warning: Could not find f
    ile [Hivemind Root]\ext-package\lib\spring-full-1.0.1.jar to copy"

    ... ...

    Could anyone please specify a list of dependent jar files which are not
    included in this release package?

    Thanks,

    Jian
  30. Jakarta HiveMind 1.0-rc-1 Released[ Go to top ]

    Not the best place to look for help on this issue. That's what the hivemind-user at jakarta dot apache dot org mailing list is for.

    The Ant build files will automatically download dependencies. However, I haven't updated them to work properly behind a firewall ... or the ibiblio.com/maven repository may not have been online.