Hello,
So, is there no way to configure Jetty with Felix today ?
Stéphane
Richard S. Hall a écrit :
On 9/30/09 12:17, Stéphane Jeanjean wrote:
Richard S. Hall a écrit :
On 9/30/09 11:43, Stéphane Jeanjean wrote:
Richard S. Hall a écrit :
On 9/30/09 11:11, Filippo Diotalevi wrote:
On Wed, Sep 30, 2009 at 11:01 AM, Stéphane Jeanjean
<[email protected]> wrote:
With Pax Runner 1.2.0, so Felix 2.0.0, I have the same behaviour
: it seems
my jetty configuration is not used and I can see the log
"configure using
bundleresource://54/jetty.xml"
I can see my Fragment in "ps" as Installed (as I can see it with
the
previous version)
A log message is displayed "Auto-properties start:
org.osgi.framework.BundleException: Fragment bundles can
not be started." (as I can see it with the previous version) But
I think
it's normal.
Hi,
the message is normal (you cannot start a fragment), but the
fragment should be Resolved (not just Installed).
Can you try to force the fragment resolution ($ resolve<pid> )
to see
if there's a problem with fragment dependencies?
Make sure the host isn't already resolved before trying to resolve
the fragment too, since if it is then it won't be possible to
resolve the fragment.
When I try to resolve it with "resolve pid" in the console, it
seems that nothing happens (no message). The state in "ps" keeps to
"Installed".
What do you mean by "host isn't already resolved", which host we
are talking about ?
The host to which the fragment will attach. If its host is already
resolved, then it cannot attach to it. It seems like it should print
a message in that case...
When I type "resolve pid" using the shell, Pax web state is "Active"
Pax web is started automatically because I'm using web profile
through pax runner. So perhaps when my fragment is deployed using
deployURLs option, Pax Web is already started ?
That is quite possibly the issue. It needs to be installed before Pax
Web is resolved.
I believe Equinox supports dynamic attachment of fragments, but this
isn't required by the spec I believe, so relying on it is
non-portable. Even then, dynamic attachment is more restricted than
resolve-time attachment, so it still doesn't work in all situations
that resolve-time attachment does.
-> richard
Stéphane
_______________________________________________
general mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/general
_______________________________________________
general mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/general
_______________________________________________
general mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/general
