James,
> We called it our "Groove Killer" but never got enough $$ after 9-11 to
> launch it full scale. I'd like to rewrite the framework I built our
> product on using Jboss and open source it. Something like Eclipse but
> not so IDE-centric in focus. Anyway, it modeled the EJB lifecycle for
You might be interested to know that the release plan for eclipse 2.2 includes a
separation of the IDE concern from the Application Framework concern. Although it is
possible now to use Eclipse as a non-IDE platform, I believe that they are going to
support this officially, perhaps even providing a separate download just for the
application framework component.
- Matt
-----Original Message-----
From: James Higginbotham [mailto:[EMAIL PROTECTED]]
Sent: Mon 12/23/2002 12:22 AM
To: [EMAIL PROTECTED]
Cc:
Subject: RE: [JBoss-dev] Dynamic Loading/Unloading of Plugins (was: RE:
[eclipse-dev] Eclipse Project 2.2 Draft Plan posted)
> How much of what you are thinking of would be handled by:
>
> jmx
Most if not all of it - the JMX timer would be responsible for the async
work of taking down and upgrading the module and its dependencies. In
addition, the rich client platform would benefit from JMX itself. The
only problem is transports between rich clients, but that is out of
scope for long enough that the JMX spec should catch up anyway. Besides,
JXTA could handle that if I really needed peer-to-peer rather than a
more client-server approach. Or, I could just use your built-in
clustering using JavaGroups as another option.
>
> jboss service lifecycle
All of it, as I would see a "module" as the equiv of an EJB on the
client side from the standpoint of componentized development and the
need for component lifecycles. I actually built a similar application
that was Swing-based, used JXTA, and resembled something like Groove..
We called it our "Groove Killer" but never got enough $$ after 9-11 to
launch it full scale. I'd like to rewrite the framework I built our
product on using Jboss and open source it. Something like Eclipse but
not so IDE-centric in focus. Anyway, it modeled the EJB lifecycle for
the "modules" and provided a "Module context" for accessing known
platform services, plus a service locator for a more dynamic lookup
(including web services on the desktop over JXTA - that was fun!).
>
> jboss mbean dependencies enhanced by including the version as
> a key in the ObjectName and using queries or filter
> conditions rather than equality for resolution of dependencies.
Jboss dependencies would be a must. I hadn't thought about versioning in
the name.. In the past I've shyed away from things like that in a
"name", but since its unique to the JMX container, that should be fine..
Like encoding the version number in a OID I guess.
>
> BTW in jboss 4 clients using the trunk invoker already have jmx client
> side: others will follow when I get to work on tx
> propagation for the other transports.
True, but I would want the JMX container initialized first thing..
Consider the typical startup as something like splash, init Jboss
Kernel, Load core platform services, load user services, launch user
application.
>
> david jencks
>
James
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
N隊X'u)Y\gbH zG( %,ׯzZ)홨x%In,uޖfz{elqzm?X( ~zwXb?,ׯzZ)
