[jboss-dev] OSGi removed from 'all' profile
Thomas Diesler
thomas.diesler at jboss.com
Fri Apr 9 07:38:32 EDT 2010
FYI, here a transcript of the chat that I had with Dimitris
Friday 09 April 2010
...
[12:38:37] Thomas Diesler: The discussion is however relevant for the
upcoming M3 release. ;-)
[12:45:25] Thomas Diesler: the beauty about smoke-tests is that folks
actually run them often
[12:45:45] Dimitris Andreadis: i know, but your test target will also
show up in hudson runs
[12:45:45] Thomas Diesler: thats why I wanted osgi coverage in there out
of the box
...
[12:46:28] Thomas Diesler: again, whats your concern against osgi being
part of 'all'? is it just boot time?
[12:46:42] Dimitris Andreadis: yea, boot time
...
[12:51:20] Dimitris Andreadis: I think the 'osgi' config is a good first
step to show that "we do OSGi", too. And we can take it from there
depending on user interest.
[12:53:59] Thomas Diesler: my main concern with that approach is that
other services i.e. ejb3, web, hornetq, etc. would not work as expected
when a user installs jbosgi using the installer. Because there is no
test coverage that tests these services with osgi in place.
[12:54:07] Thomas Diesler: Here is a prime example
http://community.jboss.org/thread/150453?tstart=0
[12:54:54] Thomas Diesler: Simple EJB3 SLSB breaks when osgi is installed
[12:55:13] Thomas Diesler: Issues like this I'd like to see in the AS
hudson run
[12:55:37] Thomas Diesler: which I would not if its (only) in a separate
profile
[12:55:53] Dimitris Andreadis: but we could test for that with your
custom osgi-test config, no?
[12:57:01] Thomas Diesler: only if we run all-tests against an
'all+osgi' configuration
[12:57:18] Thomas Diesler: I claim taht it would be better to make osgi
part of all
[12:57:35] Thomas Diesler: so that all test coverage must work with osgi
in place
[12:58:01] Dimitris Andreadis: i see your point
[13:04:34] Thomas Diesler: Here is another example:
https://jira.jboss.org/jira/browse/JBAS-7909
[13:04:51] Thomas Diesler: the 'default' profile would not even boot
with osgi in place
[13:05:17] Thomas Diesler: because the AOP subsystems makes certain
assumptions that osgi bundle deployments do not sattisfy
[13:05:59] Thomas Diesler: stuff like this I'd like to catch early
before I want to ship osgi as part of AS
[13:06:07] Dimitris Andreadis: in that case the only way to satisfy
everybody is to copy over osgi for all tests and remove it afterwards.
[13:06:20] Dimitris Andreadis: i.e. make all-test a custom config
[13:06:38] Thomas Diesler: that would work
...
[13:07:47] Dimitris Andreadis: maybe you can throw the idea/reasoning on
the dev-list thread
[13:08:26] Thomas Diesler: sure, let me add the boot time delta
[13:08:38] Dimitris Andreadis: yes, thats imporant
[13:19:17] Thomas Diesler: on my machine I get 'all' config boot times of
osgi excluded: ~ 1:17min
osgi included: ~ 1:37min
This is an increase of ca. 29%
[13:19:50] Dimitris Andreadis: 1:17 is a lot already
...
[13:28:05] Dimitris Andreadis: all+osgi: 1:02
[13:29:52] Dimitris Andreadis: all-osgi: 49
[13:30:33] Dimitris Andreadis: +26.5%
[13:31:26] Thomas Diesler: same result
[13:31:31] Thomas Diesler: so what do you say?
[13:33:13] Dimitris Andreadis: do the isolated testing anyway (custom
config with smoke tests + osgi tests anyway) and discuss if we should
alter the all testing
[13:33:36] Thomas Diesler: ok
Full transcript
---------------
Friday 09 April 2010
[12:38:04] Thomas Diesler: Hi Dimitries, shall we continue this
discussion for a short while here? Nobody else seems to be concerned
anyway. :-)
[12:38:37] Thomas Diesler: The discussion is however relevant for the
upcoming M3 release. ;-)
[12:39:00] Dimitris Andreadis: Jason will be online in a couple of
hours, I suppose he'll reply, too.
[12:39:28] Dimitris Andreadis: I think it's ok as it is now, with the
osgi config
[12:39:33] Thomas Diesler: perhaps we can reach a consensus until then.
it could safe him some time
[12:40:13] Dimitris Andreadis: But needs better testing, maybe a special
test target with a custom config if you want to test combinations with
other components not included in the osgi config
[12:42:06] Thomas Diesler: smoke-tests would also run against 'default',
right?
[12:42:25] Dimitris Andreadis: i think it runs against all
[12:42:51] Thomas Diesler: I could try to create an osgi-test profile on
top of default and rune the existing smoke tests + some osgi smoke tests
against that
[12:43:30] Thomas Diesler: yes, it runs against 'all', but I mean
'default' would be sufficient for the smoke tests
[12:44:03] Dimitris Andreadis: i think there is one or two tests run by
the smoke test target that need clustering (i.e. all) but you could
leave those 2 out.
[12:44:18] Dimitris Andreadis: but that sounds like a plan
[12:44:48] Dimitris Andreadis: i.e. osgi-test with the smoke test (minus
a couple) plus your own osgi tests
[12:45:25] Thomas Diesler: the beauty about smoke-tests is that folks
actually run them often
[12:45:45] Dimitris Andreadis: i know, but your test target will also
show up in hudson runs
[12:45:45] Thomas Diesler: thats why I wanted osgi coverage in there out
of the box
[12:46:25] Dimitris Andreadis: osgi might be deployed in the default
config, but let's give it some time, I think.
[12:46:28] Thomas Diesler: again, whats your concern against osgi being
part of 'all'? is it just boot time?
[12:46:42] Dimitris Andreadis: yea, boot time
[12:47:10] Dimitris Andreadis: I tell you, it will be much more
"advertised" if you leave it in its own profile for now.
[12:47:32] Dimitris Andreadis: ..and it looks good, i must say, I've
just tested it.
[12:47:41] Thomas Diesler: sure, but I would have an separate 'osgi'
profile anyway
[12:47:48] Dimitris Andreadis: ok
[12:48:03] Thomas Diesler: I just think it might be sensible to have it
in 'all' as well
[12:48:14] Thomas Diesler: let me have a look at the boot time
difference ...
[12:49:02] Dimitris Andreadis: you could also make an ant script in
/docs/examples that just copies over whatever is need from the 'osgi'
config to the 'all' or 'default' config, if users want it integrated.
[12:50:17] Thomas Diesler: I have an installer ;-)
http://jbmuc.dyndns.org/jboss-osgi/userguide/html/ChapGettingStarted.html#SecInstall
[12:50:27] Dimitris Andreadis: ok :)
[12:51:20] Dimitris Andreadis: I think the 'osgi' config is a good first
step to show that "we do OSGi", too. And we can take it from there
depending on user interest.
[12:53:59] Thomas Diesler: my main concern with that approach is that
other services i.e. ejb3, web, hornetq, etc. would not work as expected
when a user installs jbosgi using the installer. Because there is no
test coverage that tests these services with osgi in place.
[12:54:07] Thomas Diesler: Here is a prime example
http://community.jboss.org/thread/150453?tstart=0
[12:54:54] Thomas Diesler: Simple EJB3 SLSB breaks when osgi is installed
[12:55:13] Thomas Diesler: Issues like this I'd like to see in the AS
hudson run
[12:55:37] Thomas Diesler: which I would not if its (only) in a separate
profile
[12:55:53] Dimitris Andreadis: but we could test for that with your
custom osgi-test config, no?
[12:57:01] Thomas Diesler: only if we run all-tests against an
'all+osgi' configuration
[12:57:18] Thomas Diesler: I claim taht it would be better to make osgi
part of all
[12:57:35] Thomas Diesler: so that all test coverage must work with osgi
in place
[12:58:01] Dimitris Andreadis: i see your point
[13:04:34] Thomas Diesler: Here is another example:
https://jira.jboss.org/jira/browse/JBAS-7909
[13:04:51] Thomas Diesler: the 'default' profile would not even boot
with osgi in place
[13:05:17] Thomas Diesler: because the AOP subsystems makes certain
assumptions that osgi bundle deployments do not sattisfy
[13:05:59] Thomas Diesler: stuff like this I'd like to catch early
before I want to ship osgi as part of AS
[13:06:07] Dimitris Andreadis: in that case the only way to satisfy
everybody is to copy over osgi for all tests and remove it afterwards.
[13:06:20] Dimitris Andreadis: i.e. make all-test a custom config
[13:06:38] Thomas Diesler: that would work
[13:07:47] Dimitris Andreadis: maybe you can throw the idea/reasoning on
the dev-list thread
[13:08:26] Thomas Diesler: sure, let me add the boot time delta
[13:08:38] Dimitris Andreadis: yes, thats imporant
[13:19:17] Thomas Diesler: on my machine I get 'all' config boot times of
osgi excluded: ~ 1:17min
osgi included: ~ 1:37min
This is an increase of ca. 29%
[13:19:50] Dimitris Andreadis: 1:17 is a lot already
[13:20:38] Thomas Diesler: slow machine (yawn)
[13:21:00] Dimitris Andreadis: just trying out mine (another slow machine)
[13:21:23] Dimitris Andreadis: all: 1:10
[13:21:53] Thomas Diesler: 1011 cp -r
server/osgi/deployers/osgi.deployer server/all/deployers/
1012 cp -r server/osgi/deploy/osgi server/all/deploy/
[13:22:31] Thomas Diesler:
cp server/osgi/conf/bootstrap/deployers.xml
server/all/conf/bootstrap/deployers.xml
[13:25:02] Dimitris Andreadis: trying it out with osgi...
[13:26:11] Dimitris Andreadis: all+osgi: 1:04
[13:26:14] Dimitris Andreadis: ?
[13:26:29] Thomas Diesler: we are all set then :D
[13:26:42] Dimitris Andreadis: am on WinXP
[13:26:44] Dimitris Andreadis: :)
[13:27:15] Dimitris Andreadis: i'll make a 2nd try, it's probably cached
at the filesystem level
[13:28:05] Dimitris Andreadis: all+osgi: 1:02
[13:29:52] Dimitris Andreadis: all-osgi: 49
[13:30:33] Dimitris Andreadis: +26.5%
[13:31:26] Thomas Diesler: same result
[13:31:31] Thomas Diesler: so what do you say?
[13:33:13] Dimitris Andreadis: do the isolated testing anyway (custom
config with smoke tests + osgi tests anyway) and discuss if we should
alter the all testing
[13:33:36] Thomas Diesler: ok
On 04/09/2010 12:24 PM, Dimitris Andreadis wrote:
> What I've seen is most users taking the existing configs as-is and
> adding their deployments, with small modifications. If they want
> cluster support they just pick the 'all' config. Advanced users might
> try to trim down unused services but many will just leave what is
> already there.
>
> I definitely think osgi support should be tested as part of the
> testsuite to spot regression and test osgi in combination with other
> subsystems. But this can always be done by just creating and booting a
> custom config based off of 'default', as many other tests do, e.g. a
> lot of security tests. So that could make a separate testing target.
>
> In any case, this whole discussion will not be much relevant as jboss
> AS evolves and gives you more freedom to define your configuration, or
> just have everything available and on-demand activated.
>
> Thomas Diesler wrote:
>> As of yesterday we had osgi part of the 'all' profile and a separate
>> 'osgi' profile. The idea was that integration issues with osgi would
>> show up early in the 'all' testsuite and I can have osgi smoke tests
>> as part of the smoke-tests target. The osgi profile would only
>> contain services that are (at least to some degree) integrated with
>> osgi. i.e. TM is, EJB3 is not
>>
>> For a better understanding, are users really running the 'all'
>> profile? I thought this was more a 'pick and choose' repository of
>> stuff.
>>
>> My own QA installs osgi in 'default' and runs 90+ tests on it. It
>> would however not detect that the osgi installation breaks EJB3 tests.
>>
>> I guess we have two options
>>
>> #1 install osgi in 'all' and integrate it in smoke-tests and
>> all-tests. So we always know that osgi works together with all the
>> other stuff. Additionally we could distribute a stripped down 'osgi'
>> profile.
>>
>> #2 install osgi in its own profile only. Only osgi functionality is
>> tested there and we move bits in there over time that actually have
>> integration and test coverage.
>>
>> Both would work work for me.
>>
>> cheers
>> -thomas
>>
>> On 04/09/2010 11:11 AM, Dimitris Andreadis wrote:
>>> Although a separate 'osgi' profile/config increases the distro size,
>>> I think too, it's better to have it separate from 'all'.
>>>
>>> If you include it in 'all', it will increase the already long boot
>>> time, and the functionality will get lost together with everything
>>> else that is already there. Also 'all' is usually the base for EAP
>>> 'production' and we might not want to offer full OSGi support, as yet.
>>>
>>> On the other hand, having it separately, makes it stand out and will
>>> trigger more people to try it out, start experimenting with it and
>>> provide feedback. When at a later time, JBoss-OSGi becomes more
>>> integrated with the other subsystems (EJB3, etc.) we might re-consider.
>>>
>>> I would even suggest that at some point we drop the 'minimal' config
>>> in favor of 'osgi', in the sense that if people want a bare runtime
>>> to write server extensions, they might be better off going with the
>>> OSGi standard.
>>>
>>> My 0.02c
>>>
>>> Thomas Diesler wrote:
>>>> Hi Jason,
>>>>
>>>> I see that you removed OSGi from the 'all' profile. Were there any
>>>> specific issues with it? I couldn't find pointers to why this was
>>>> necessary.
>>>>
>>>> I reopened https://jira.jboss.org/jira/browse/JBAS-7661 where I
>>>> make a comment on why I think osgi should be part of the 'all'
>>>> profile. I am now working on osgi smoke tests that I ultimate want
>>>> to run against 'all' as part of the smoke-tests target.
>>>>
>>>> cheers
>>>> -thomas
>>>>
>>
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
More information about the jboss-development
mailing list