Posted
7 months
ago
First off the JBoss Microcontainer is a big step forward for JBoss. It will hopefully let the meaty parts of the appserver unhinge from the gooey stuff that is the API. However, I can't help but not think that it is that big of the deal for the
... [More]
rest of the world. First off, since Spring added annotations as seemingly first class citizens, I think the only profound step forward for the JBoss Microcontainer is:
Hibernate Annotations/EJB3 as first class citizens (you can even scan a directory for them with an ant task from a plain Java application)
Designed rather than organic. This is like "gee if we had it to do all over today we would..." This is especially apparent when you DO write XML. Spring's XML has always made me gag. The JBoss MC ones only make me slightly sick to my stomach.
Persisted attributes. This was most of the point really. Somewhere this was supposed to be configurable to different stores. This seems under documented.
Springy people are going to comment and tell me how wrong I am about even these things and that is fine, but I've actually looked and at least run both where they'll just run around looking for anything that is positive about anything else and "correct" (I only like one "evangelist" in the world and think the rest of you are techno-scum and worse the kind that aren't paid to do it are messed in the head to boot) :-).
For JBoss users the Microcontainer is probably going to be a snoozer. They're probably going to find more third-party reference material and tutorials on Spring and even Guice. There probably will be better Eclipse tools and other tool integration for Spring. For JBoss internals this will probably be a big deal. For users of OTHER appservers, this is a biggy as JBoss is developing some really good stuff that will no longer be strictly bound to JBoss. In some ways I hope this along with OSGi support shrinks JBossAS and allows it to finally be right-sizable by dumb people.
For Meldware this misses the mark because it still "by Java developers and for Java developers". It doesn't abstract configuration from Java. Meldware users don't as a whole care much about Java. The developers mostly whine about it as it is a means to an ends and not all that interesting in itself.
<javabean xmlns="urn:jboss:javabean:2.0" class="org.jboss.test.javabean.support.SimpleBean">
<property name="ADouble">3.14e12</property>
<property name="ADate">Jan 01 00:00:00 CET 2001</property>
<property name="ABigDecimal">12e4</property>
<property name="ABigInteger">123456</property>
<property name="abyte">12</property>
</javabean>
JBoss MC "javabean" descriptor
How many system administrators do you think really want to think about WHAT class we implemented the SMTP Protocol in? How many do you think want to know what class we implemented the socket listener in? Probably pretty few. They may want to declare another socket bound to the same SMTLSSL service they defined but I can't imagine that they want to type all this org crap. Secondly try writing a tool that can not only read, write but update this!!! (I did for JBossMX the MC predecessor and it hurts my head)
For us we want a way to use Java to define a service "smtp" and then configure the service:
exampleService {
type = example
setting = "settingValue"
anotherSetting = 4
}
bkernel prototype out of a unit test
Where did all the Java crap go? It is behind the definition of "example" which is either an annotation or in another file somewhere. It probably never changes so WHO CARES. It is a "type" of thing to be configured. Indeed this may also look like:
...
dn: ou=Services,dc=buni,dc=org
objectClass: organizationalunit
objectClass: top
ou: Services
dn: cn=Service,ou=Services,dc=buni,dc=org
ObjectClass: bkernelService
objectClass: top
setting: o=setting,cn=Service,ou=Services,dc=buni,dc=org
setting: o=anotherSetting,cn=Service,ou=Services,dc=buni,dc=org
cn: Service
dn: o=setting,cn=Service,ou=Services,dc=buni,dc=org
ObjectClass: bkernelServiceSetting
objectClass: top
value: settingValue
o: setting
dn: o=anotherSetting,cn=Service,ou=Services,dc=buni,dc=org
ObjectClass: bkernelServiceSetting
objectClass: top
value: 4
o: anotherSetting
LDIF from one of Andy's nightmeres
That looks like something logical exploded and its guts were left on the road but that is not intended to be written by hand but generated by tools or processes inside of LDAP. The advantage is that you can centralize configuration in a directory with replication and all that cool stuff. Moreover this stuff is poorly expressed in a relational database as the stuff is really more of a tree and walking a tree in ANSI SQL is at least horrible.
The point is that the microcontainer is still just Spring reloaded. For me it isn't very useful because I can't abstract the Java out of my configuration. For Java Application developers who do not work with non-Java programmers, "who cares". For me...it's just another flavor of the same stuff we've all been smoking for a few years now. Let's have some config files that don't look like throw-up and don't expose your guts to the world. For JBoss...when is JBossAS 5 coming out again (okay I'm a hypocrite but it is still a good question)? [Less]
Posted
8 months
ago
The other day I wrote on Sun's dirty tricks re: the apparently not quite open
source OpenDS. Sun's new "OpenDS Community Leader" Ludovic Poitou has posted a response that more or less calls
all the developers Sun let go -- for their not
... [More]
being French* and
then subsequently forced out of the project -- liars. *(this is the
only explanation that has been given up until now). Following this I posted that I didn't really feel the response was all that
satisfying. To which the Distinguished
Engineer posted a challenge to suggest a response that would be
satisfying. I replied:
The license is not enough to create open source. Your governance model
is de facto shared-source if not de jure.
The obvious:
1. Restore all developers who were forced to resign
2. Restore the governance to the state prior to your recent
reversion
3. Discuss the proposed changes with the full community.
4. Management apology for this behavior and a promise that it will
not
happen again.
The ideal:
5. Rehire those developers who want to come back in their previous
positions.
Not surprisingly he didn't like that response and since Sun has done
something dirty they'd like to "move on" (read: get away with it and
admit no wrong doing, free to do it again in the future). So he reiterated that all the former Sun employees whom myself and
others had come to respect technically and believe had a sincere desire
to do REAL open source were liars who had dirtily sneakily made Sun's
project open.
Shockingly one of the other OpenDS developers, Trey Drake (who was fired and then pushed off the project),
didn't like being called a liar and evildoer and clarified:
Enough. I have attempted to stay out of the fray as I find the whole
thing embarrassing as I initiated the governance change. As the
previous OpenDS Community Leader I was deeply involved in the
community and was the primary advocate for making OpenDS and the
broader Identity Management community more open, transparent and
independent. The change in question was the result of months of
discussion amongst the owners, myself, and the eventual Identity
Management community owners (which included me). To say that it
wasn't "Sun approved" is incorrect. There were no less than 2 Sun
officers (Directors), an engineering manager, a principal engineer,
and the previous Sun appointed Project Lead involved in the change.
As an advocate for the community, I wanted to take these changes
further to ensure that there were non Sun users on the ownership board
and explicitly state that community participants represent themselves
not their employer. The adopted change was a first, conservative step
in that direction. The idea behind this and other changes was
inspired by Jonathan's vision for Sun's growth and credibility in the
OSS community. The "doacrcy" is nothing new and based on very
successful OSS communities; i.e., Apache, Eclipse...
As for the broader community - I personally bounced the change off a
select group of OpenDS users, but not the entire community on the
public mailing list. In hindsight, I suppose this change should have
been sent out over the public alias, but to what end? Would anyone,
in the OpenDS user community have disagreed with a freer, more open
project? The change was not swept under the rug nor done in secret.
Ludo, you and others may have "just discovered" the change because you
were not involved in the OpenDS project until shortly before we were
laid off. Please don't attempt to cast a negative shadow over our
previous efforts as OSS advocates.
From the preceding thread and claims by Neil, it appears that Sun
requires ultimate authority over projects it deems critical to their
success. There are many java.net projects initiated and entirely
staffed by Sun employees with weaker and, in fact, no governance
whatsoever. Current Sun employees may claim that they didn't see nor
approve the change and that may be a true statement. It is also true
that there was no clear need to consult these employees on the
change. So, what's your point?
Lastly, I haven't seen any public discussion or legitimate reasoning
for reverting back to the post April governance. Reasoning that "we
didn't approve" and hence this is a correction implies there was a
previous wrong. You have chosen to change the governance as you see
fit. As the only project owners you have that right, but don't
discredit the previous leadership and claim the moral high ground in
doing so.
I do think that Trey made some mistakes here. The changes should have been vetted publicly. It isn't that you agree or disagree -- and he's right -- it is hard to imagine anyone in open source disagreeing with more openness (though it does happen). However it isn't that you agree or disagree. It is that you showed everyone the respect for their input. Do that enough and you get an open source project. If you don't, you get a shared source project. Sun is demonstrating this very clearly now. Trey breeched some etiquette, not more. Sun burned the house down. It isn't the same thing.
After 1.0 we'll probably migrate away from OpenDS. It makes me sad though, it is a technically excellent but dysfunctional non-open source project. I was duped. I thought that so long as the OpenDS developers were sincere about the desire to do this as real OSS that the details would work themselves out. I didn't anticipate just how much control Sun intends to exhibit. My imagination doesn't allow me to see the long term benefits for Sun to exhibit this much control and simultaneous pretend that it is open source. I think they'd be better off just keeping it proprietary or shared source and giving up the pretense and headache if they don't give a damn what anyone else thinks unless they immediately agree with Sun. If you don't get to vote with your hands, vote with your feet.
Update: Simon Phipps who is kind of a PR Sock-puppet for Sun's open source misadventures, has commented. Basically whenever Sun gets caught with their hands in the cookie jar they get Simon to act as a "voice of reason" and try and convince people it is okay. Simon views himself as a "man on the inside" but in reality rarely reads from a different script. Oddly he's "still looking into it" but is PERFECTLY voiced in Sun's talking points...lame as they are. What is good for Sun (in their shortsided view) is good for the community!
Another Update: Thanks to Ken Coar for This excellent summation of how Sun often misses when it tries to grok open source. [Less]
Posted
8 months
ago
I'm totally going to buy one of the new Android phones when they come out. Today in less than 5 minutes I managed to get the SDK, Eclipse plugin installed and create the Hello, Android application. I managed to write an app for their emulator and
... [More]
run it before the phone even came out whereas it took me an entire day just to figure out how to get my palm to work with bluetooth on Linux. Better yet, it looks like they're licensing the important parts under open source licenses. It looks like these will be real open source licenses that we're familiar with already (not just some license sanctioned in a secret meeting by a closed and non-representative body pushed by some VC afraid that open source will screw up his "enterprise upgrade" strategy). Contrast this with the Palm where they freaking make it hard to even do hello world with their horrible SDKs or the iPhone which is a monstrous "all your data are belong to us" plan by apple. I think Android is probably going to do for phones what the IBM PC did for microcomputers. The evidence is there. When something doesn't matter, no one comments on it. When something matters they comment on why and how much it doesn't matter. [Less]
Posted
8 months
ago
This is a pretty disturbing read. Early on I voiced my concerns that maybe OpenDS was only pseudo-open source. This seems to confirm that. Maybe we made the right technical choice in using it, but maybe we do need to consider the community aspects
... [More]
a little more closely in our technology choices. Alex K. can laugh at me now...if only the ApacheDS build and config process wasn't ass.
PS. Who in their right mind would relocate open source development to Europe right now...from a financial standpoint the move seems...stupid (anyone notice the Euro vs Dollar right now)...not to mention the "IK" factor...Sun never seems to miss an opportunity to shoot themselves in the foot.
UPDATE: my original post had a broken link (ref is not valid ;-) )... This is fixed. The "IK" factor is a Marc Fleuryism that explained why...a certain company...got it wrong...if I recall correctly. JBoss did not need "Intellectual Property" IP because we had "Intellectual Knowledge". Meaning we had all the guys who wrote the thing and had been working in it and knew RIGHT where the ins and outs of the code were without having to even look at it. Building a new open source developer is really actually very expensive. Losing a good one for no reason is not cheap. I say "no reason" because Sun is doing this to...SPEND EUROS as opposed to DOLLARS? Where is THAT business sense. The importance of co-location is greatly diminished in open source. It might not be 0 but certainly isn't worth the loss of IK, relationships and good will. I'm hoping Marc picks this up and expounds on "IK" a bit. [Less]
Posted
9 months
ago
Last night TriLUG hosted Pat Patterson (the identity expert and not the wrestler) on identity. This was what many, including myself, thought was one of the best talks we'd attended. I could tell Pat was sweating it as the announcements and time
... [More]
ticked off (I'd promised him close to 2 hours as our announcements and AV setup usually take less time). He managed in 90 minutes to bring over 60 people up to speed on the whole of the "Digital Identity" space, at least from a high-level perspective. You can find the slides: here and the audio: here. I'm the guy who asked all the stupid questions (as usual).
My only complaint is that Pat is a "Font Sinner". He used "Arial Narrow" on his iMac which renders differently on my Ubuntu box. Ideally, he'd have used a free and multi-platform font like: Red Hat's Liberation fonts or the BitStream fonts. This is less of a problem with his PDF rendering, but initially he gave us ODP files which rendered poorly. In essence, when distributing a PPT or ODP or whatever, use a free/multi-platform/unique named font set like Red Hat's Liberation Fonts or the BitStream fonts. When distributing PDF it only matters ideologically (my issue is that stuff doesn't render right rather than the ideological issues). [Less]
buni freebusy evolution wcap cross-platform outlook lightning sunbird flex oracle pop postgresql bayesian filter flash javascript mta smtp mda enterprise antispam scheduling webmail imap mail_transport_agents spam ical email communications windows java collaboration mysql server internet calendar mac thunderbird linux
|
edit tags
