Deploying artifacts that should be deployed before server is started
by Galder Zamarreno
Hi,
From what I understand the way deployments work in JBoss AS servers is
that the server is started and then deploy() is called with the
deployments, is that correct?
If so, what do u do when you wanna deploy things that should be deployed
before AS is actually started since they affect services loaded on startup?
Regards,
--
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
15 years
JSR-77 Summary
by Rob Stryker
JSR-77 allows, via JMX, to get a list of which servers are running,
which modules they have, which resources they have, etc. From this model
I can make an effective list of what's deployed on the server through
simple JMX calls.
What I still cannot do, though, is control the modules. The portions of
the spec which deal with managing (starting, stopping) the modules is
optional, and JBoss does not support this. So, while I can get a nice
list of what's deployed / running, I cannot manage any of it.
Is it worth-while for me to add to the Servers View a tree element (and
children) dealing with deployed / running modules considering I cannot
control them? Is this worth pushing up to the platform to force them to
implement when JSR-77 is being removed in the future?
Thoughts appreciated.
- Rob
15 years
Moving to Eclipse 3.5 drivers
by Max Rydahl Andersen
Hi,
At EclipseCon/Tools meeting last week we discussed the necessity of
moving the 3.1/trunk work onto Eclipse 3.5 M builds as soon as possible so
we:
1) Can get any fixes/changes into Eclipse that we need/want before they
API freeze (in a month or so)
2) Develop on a platform that will actually be supported by Eclipse
(Eclipse 3.4 won't get more fixes in)
Could you please let me know if you have any problems/issues with this
happening ?
i.e. JBoss Tools 3.0.x will still require Eclipse 3.4, it is just for
trunk/upcoming major releases we will be moving.
-max
15 years
Re: [jbosstools-dev] Moving to Eclipse 3.5 drivers
by Max Rydahl Andersen
> One issue we have is that Drools cannot support more than one Eclipse
> version using the same code base. We are dependent on some internal
> eclipse java classes to get the rule debugging working (the Java
> debugging was not really written to be extended / reused, at least not
> when we implemented debugging and I guess the situation is still the
> same), and those internal apis tend to change a little every release.
> I just checked and a few methods were added again. This means we
> would have to maintain two parallel branches, one for Eclipse 3.4 and
> one for 3.5.
That was what I feared would be the case for Drools. Any chance you
could identify these so we could do a push for getting the API you
depend on public instead of internal so
we can reduce this going forward ?
> Based on the impression that they are targeting Eclipse 3.5 GA end of
> June, I guess the following options are possible:
> 1. after Drools 5.0 GA (supporting Eclipse 3.4.x) this weekend we move
> to Eclipse 3.5.x, all new features implemented for Drools 5.1+ Eclipse
> IDE will be for Eclipse 3.5 only
> 2. after Drools 5.0 GA we keep working on this code base (supporting
> Eclipse 3.4.x) and we branch the last week before Drools 5.1, so at
> that point both Eclipse 3.4 and 3.5 are supported for Drools 5.1,
> after that all new changes are for Eclipse 3.5 only
> 3. after Drools 5.0.GA create a new Eclipse 3.5 code base immediately,
> next to the Eclipse 3.4 code base, and commit all changes to both,
> until we decide the 3.4 branch no longer needs to be kept up-to-date
> with the latest features
>
> Obviously, option 3 requires a lot more work. I'd go for option 2 as
> it has the advantage of being able to support both 3.4 and 3.5 for
> 5.1, but that means we won't be able to migrate to Eclipse 3.5 soon.
Understood.
> On the other hand, the changes required to get this working on Eclipse
> 3.5 are probably pretty minimal, maybe we can write some automatic
> patch script that could automatically patch our Eclipse 3.4 code so it
> supports 3.5, thus removing the need to maintain two separate
> branches? And JBoss Tools trunk could use the patch script and
> include the Eclipse 3.5 version, would that be possible?
hmm - wouldn't it actually be easier to maintain two separate branches
than a patch file ? Or at least have the patch file be to "downgrade"
3.5 code to 3.4 so the codebase "just works" on 3.5 ? Reason: I assume
there we will be far more dev's having the drools codebase checked out
using Eclipse 3.5 than 3.4.
/max
15 years
Running UCDetector to remove obsolete resourcebundle messages
by Sean Flanigan
Hi,
I've run UCDetector [1] against the codebase, and it has found 294
fields in *Messages classes which have 0 references. I've attached a
list (views well in oocalc). I'd like to remove them, along with their
corresponding resourcebundle properties, to reduce the number of
translatable strings.
UCDetector also finds lots of unused methods and classes (which may be
referencing even more obsolete strings), but I'm wary of false
positives, so I won't try to tackle them. But if anyone else wants to
run UCDetector against their code, I would appreciate it! (Or I could
export a larger TSV file if you don't feel like installing UCDetector.)
1. Is removing those messages a bad idea, for some reason I can't think of?
2. Should I do this under JBIDE-3557, or should I create a new task,
perhaps a sub-task?
[1] http://ucdetector.sourceforge.net/
Sean.
--
Sean Flanigan
Senior Software Engineer
Engineering - Internationalisation
Red Hat
15 years
