Yang Bob | 1 Nov 02:18
Picon

Re: how to change the jetty port from 80 to other

Hello Simon,

Thanks very much for your help and remind.

2007/10/31, Simon Kaegi <Simon_Kaegi@...>:
> Hi Bob,
>
> These sorts of question should normally be asked in the user newsgroup
> instead of the dev list.
>
> You can configure the Jetty Server in a number of different ways:
> 1)  System properties (prefix the properties you found with the bundle name
> -- e.g. -Dorg.eclipse.equinox.http.jetty.http.port=8080)
> 2)  JettyConfigurator (see
> http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/api/org/eclipse/equinox/http/jetty/JettyConfigurator.html)
> 3)  ConfigurationAdmin (The config.xml file you found is actually for use
> with the metatype service in conjunction with ConfigAdmin.)
>
> HTH
> -Simon
>
>
> equinox-dev-bounces@... wrote on 10/31/2007 02:01:36 AM:
>
> > Hello everybody,
> >
> > I am new to the Equinox, I am coding a sample application by following
> > the article " Embedding an HTTP server in Equinox".
> >
> > I coded a servlet and want to start a jetty server in Equinox. The
(Continue reading)

Andrew Overholt | 1 Nov 02:46
Picon
Favicon

[prov] M3 Testing status on Linux

Here's what I've found so far while running the tests.  I'll finish the
rest tomorrow.

1. Basic install, run and update

- do not exit admin UI in between

✓ new profile creation
✓ installing 3.4M2 sdk
✓ running provisioned install
✓ update using admin UI
✓ run and verify updates applied
✓ verify updates in admin ui

- exit admin UI in between

✓ new profile creation
✓ installing 3.4M2 sdk
✓ running provisioned install
✓ update using admin UI
✓ run and verify updates applied
✓ verify updates in admin ui

2. Basic install, and update

✓ new profile creation
✓ installing 3.4M2 sdk
✓ Using the Admin UI:
✓ - look for updates, install eclipse SDK 3.4 M3 
✓ Run and verify that the plugins have been changed
(Continue reading)

John Arthorne | 1 Nov 03:28
Picon

Re: [sec] questions about EE for security


I think the right approach is to set your bundle's EE to reflect the EE dependencies of *your* bundle, and not the bundles you depend on. I.e., if your bundle doesn't directly depend on 1.4, you could still specify an EE of Foundation 1.1 for your bundle.  If it turns out that the JAAS bundle requires 1.4, then your bundle will transitively fail to resolve anyway. That way you're not building assumptions into your bundle about the EE of downstream bundles that may change in the future.

John



Scott Lewis <slewis-moQcexxCXgLby3iVrkZq2A@public.gmane.org>
Sent by: equinox-dev-bounces-j9T/66MeVpFAfugRpC6u6w@public.gmane.org

10/31/2007 05:53 PM

Please respond to
Equinox development mailing list <equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org>

To
Equinox development mailing list <equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org>
cc
Subject
[equinox-dev] [sec] questions about EE for security





Hi Folks,

Some questions:  I thought I understood (from Equinox Summit) that the
recently approved minimum EE for Equinox 3.4 (Ganymede) was CDC
1.1/Foundation 1.1.

I see from looking at the equinox JAAS integration bundles (e.g.
org.eclipse.equinox.security.auth) that the runtime environment minimum
for those bundles is set to JRE 1.4.  I understand this, as the JAAS
work depends upon packages like javax.security.auth, and
javax.security.auth.login, etc.  which do not seem to be in CDC
1.1/Foundation 1.1.

So maybe I just answered my own question:  it seems that the JAAS
security bundles/plugins must assume JRE 1.4 (and can't/won't run on CDC
1.1/Foundation 1.1).  So the implicit (to me anyway) idea here is that
bundles that use/extend/depend upon the JAAS security integration also
obviously must assume JRE 1.4 and not just CDC 1.1.  Correct?

Scott


_______________________________________________
equinox-dev mailing list
equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

John Arthorne | 1 Nov 04:22
Picon

Re: [api tooling] Re: Using component.xml as a starting point


There are cases where you want a component.xml file (or something similar) when you don't want to or can't mark up the source, but I don't see any reason why someone would want to maintain both a component.xml file and javadoc tags in the source for the same API. So, a one-off tool for inserting javadoc tags based on a component.xml sounds useful, but I wouldn't bother getting any fancier than that.



Darin Wright/Ottawa/IBM <at> IBMCA
Sent by: equinox-dev-bounces-j9T/66MeVpFAfugRpC6u6w@public.gmane.org

10/29/2007 04:54 PM

Please respond to
Equinox development mailing list <equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org>

To
equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org
cc
Subject
[equinox-dev] [api tooling] Re: Using component.xml as a starting        point






We are getting close the chicken and egg problem here....

When it's time for developers to start using the tooling, we want to make it easy - so yes, it would be handy to have a tool that inserts javadoc tags based on existing component XMLs. I think the tags "replace" component.xml - so I don't think we should have tooling to keep the two in synch. I would see this as a "one off" tool to get started. For that reason, I don't think we would want to create markers as it would require "active" tooling to keep the two in synch. As well, we'd have to have some mechanism for knowing if the "component.xml" should be considered as the "source" for tag generation, or the "target" for caching existing tags. It feels awkward to have duplicated information in the IDE - when the user can edit both. Would it be better to have a tool/action/wizard that processes the component XML and generates a report for issues (rather than makers)?

Does anyone think that we should have tooling to maintain the "component.xml" files? I'd rather just use the javadoc tags as the "source" of the information in the workspace. At build time, we could also use source to generate that part of our API description.

Darin


Olivier Thomann/Ottawa/IBM

10/29/2007 02:17 PM


To
Darin Wright/Ottawa/IBM <at> IBMCA, Michael Rennie/Ottawa/IBM <at> IBMCA, Jeff McAffer/Ottawa/IBM <at> IBMCA
cc
Subject
Using component.xml as a starting point






Hi,

We should use the existing component.xml file for each plugin in the SDK to "tag" the corresponding types with the appropriate javadoc tag.
So the tool would take the component.xml and check all the API types inside the workspace.
The existing text that describes the API usage would be replaced with the corresponding tag and for the API type where the existing text is not an exact match, the tag would be added and a marker created to remember that this file should be double-checked.
The "new" API types that have been added since the component.xml was created should also be marked to be double-checked.

This could allow us to get a "good" baseline.

What do you think?

Olivier _______________________________________________
equinox-dev mailing list
equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Thomas Watson | 1 Nov 14:28
Picon
Favicon

Re: [sec] questions about EE for security

Both John and Rem are correct.

Bundles which want to run on a smaller EE than J2SE-1.4 and have access to the javax.security.auth packages should use import-package (e.g. Import-Package: javax.security.auth). You should not make J2SE-1.4 your required EE only because other bundles you depend on use the EE.

Equinox is a broad community. A large number of our bundles do run on Foundation 1.1/1.0 (and even down to the minimum OSGi EE). But there are some extra features which require higher EEs. Currently parts of the security work in the incubator can only run on J2SE-1.4 or higher. For example, the core extension bundles (org.eclipse.equinox.security.boot.jre14x or org.eclipse.equinox.security.boot.jre15x) are installed into the extension classloader of the VM. This is required because we need to make the our security provider available to the VM and it will only search for providers on the boot classpath or the extension class loader. Unfortunately at that level the code will only have access to classes that are provided by the EE. They do not have the option to import additional packages which may come from other bundles installed in a Framework running on Foundation 1.1 EE.

I opened a couple of bugs against the security bundles. All Equinox bundles should use Import-Package to access packages outside the java.* namespace. We could also split some of the bundles to allow parts of it to run on a Foundation EE.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=208399
https://bugs.eclipse.org/bugs/show_bug.cgi?id=208400

Tom



John Arthorne ---10/31/2007 09:30:11 PM---I think the right approach is to set your bundle's EE to reflect the EE dependencies of *your* bundle, and not the bundles you


From:

John Arthorne <John_Arthorne-G1DYhSM1WHTQT0dZR+AlfA@public.gmane.org>

To:

Equinox development mailing list <equinox-dev <at> eclipse.org>

Date:

10/31/2007 09:30 PM

Subject:

Re: [equinox-dev] [sec] questions about EE for security




I think the right approach is to set your bundle's EE to reflect the EE dependencies of *your* bundle, and not the bundles you depend on. I.e., if your bundle doesn't directly depend on 1.4, you could still specify an EE of Foundation 1.1 for your bundle. If it turns out that the JAAS bundle requires 1.4, then your bundle will transitively fail to resolve anyway. That way you're not building assumptions into your bundle about the EE of downstream bundles that may change in the future.

John


Scott Lewis <slewis-moQcexxCXgLby3iVrkZq2A@public.gmane.org>
Sent by: equinox-dev-bounces-j9T/66MeVpFAfugRpC6u6w@public.gmane.org

10/31/2007 05:53 PM

Please respond to
Equinox development mailing list <equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org>
To
Equinox development mailing list <equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org>
cc
Subject
[equinox-dev] [sec] questions about EE for security




Hi Folks,

Some questions:  I thought I understood (from Equinox Summit) that the
recently approved minimum EE for Equinox 3.4 (Ganymede) was CDC
1.1/Foundation 1.1.

I see from looking at the equinox JAAS integration bundles (e.g.
org.eclipse.equinox.security.auth) that the runtime environment minimum
for those bundles is set to JRE 1.4.  I understand this, as the JAAS
work depends upon packages like javax.security.auth, and
javax.security.auth.login, etc.  which do not seem to be in CDC
1.1/Foundation 1.1.

So maybe I just answered my own question:  it seems that the JAAS
security bundles/plugins must assume JRE 1.4 (and can't/won't run on CDC
1.1/Foundation 1.1).  So the implicit (to me anyway) idea here is that
bundles that use/extend/depend upon the JAAS security integration also
obviously must assume JRE 1.4 and not just CDC 1.1.  Correct?

Scott


_______________________________________________
equinox-dev mailing list
equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Pascal Rapicault | 1 Nov 15:25
Picon

[prov] p2 M3 wrap up call


Hello p2'ers,

The spooky night brought us a few good treats (a.k.a builds) that seem to
be working relatively well.
Let's quickly meet today at 11AM EDT to decide if we are ready to declare
M3.
The call info:
      International:  613 287 8000
      Toll free:  866 362 7064
      Participant passcode:  892048#

PaScaL

Andrew Overholt | 1 Nov 15:54
Picon
Favicon

Re: [prov] M3 Testing status on Linux

Here's my latest status.  I still have to finish the manual updates test
and the installation from a remote repo and automatic updates tests to
complete.  See questions and errors below.

5. Reverting

✓ Using the Admin UI:
✓ - Create a new profile
✓ - Install an SDK
✓ - Install the releng tools 
✓ Start the provisioned install
✓ - verify the presence of the releng tools 
✓ Using the Admin UI:
✓ - Revert to the state where releng tools was not installed 
✗ - does this mean just use the admin UI's uninstall operation?
✓ Start the provisioned install
✓ - verify the absence of the releng tools 

7. Bundle pool

✓ Using the Admin UI:
✓  - Create a new profile
✓  - Install the SDK.
✓ Create a second profile
✓ Install the SDK in it
✓ - During the installation notice the dialog saying that only around
    50K should be "installed".
✓ - Notice that the download phase goes much faster. 

8. Bundle pool in the eclipse install

✓ Using the Admin UI:
✓ - Create a new profile: in the dialog set the install folder and the bundle
    pool to the same location. It will be the root of your eclipse install. 
✓ Install the SDK
✓ Verify that the plugins folder is located at a subfolder of the install
  location
✓ Verify that the path in the bundles.txt are relative.
✗ Verify that the path in the osgi.bundles property of the config.ini are
  relative 
  - is this correct?
  osgi.bundles=reference\:file\:org.eclipse.equinox.simpleconfigurator_0.1.0.200711011014.jar <at> 1\:start

  in the same config.ini as:

  osgi.framework=file\:plugins/org.eclipse.osgi_3.4.0.v20071031.jar

  - it starts up fine

9. Manual updates

✓ From the Admin UI
✓ - Create a profile
✓ - Install the SDK 3.4 M2 (or any version for which you will have an update in
✓the repository)
✓ - Install the User UI 
✓ Start the provisioned SDK
✗ - need to add a step in here for adding the testUpdates repository or
    information on how to use a local repo
✓ - Go to the end user UI (Help>Software Updates (Incubation)
✗ - need to add a step in here for selecting the sdk (or whatever we
    want to update)
✓ - On the installed features page, push the "Check for Updates" button
✗ - I get the same version I installed as an option (20071031).  I
    assume this is because the randomly-generated qualifiers don't match?
✓ - You should get a dialog showing the newer version

----- Still to be completed -----

✓ - Accept the update, restart
  - still downloading
? - Verify that the end user UI now shows the new version in the installed
?   features list 

6. Install from a remote repository

? Using the Admin UI:
? - Create a new profile
? - Point your repos to the repositories produced during the build
? - Install the SDK 
? Start the provisioned install 

10. Automatic updates

? From the Admin UI
? - Create a profile
? - Install the SDK 3.4 M2 (or any version for which you will have an update in
?   the repository)
? - Install the User UI 
? Start the provisioned SDK
? - Go to the update preference and enable the auto update
? - Wait for a notification to show up
? - Accept the install, restart 
Andrew Overholt | 1 Nov 15:57
Picon
Favicon

Re: [prov] M3 Testing status on Linux

9. Manual updates

✓ From the Admin UI
✓ - Create a profile
✓ - Install the SDK 3.4 M2 (or any version for which you will have an update in
✓the repository)
✓ - Install the User UI 
✓ Start the provisioned SDK
✗ - need to add a step in here for adding the testUpdates repository or
    information on how to use a local repo
✓ - Go to the end user UI (Help>Software Updates (Incubation)
✗ - need to add a step in here for selecting the sdk (or whatever we
    want to update)
✓ - On the installed features page, push the "Check for Updates" button
✗ - I get the same version I installed as an option (20071031).  I
    assume this is because the randomly-generated qualifiers don't match?
✓ - You should get a dialog showing the newer version
✓ - Accept the update, restart
✗ - Verify that the end user UI now shows the new version in the installed
    features list 
  -- can't restart due to many errors like this:

  org.osgi.framework.BundleException: State change in progress for bundle
  "initial <at> reference:file:plugins/org.eclipse.equinox.simpleconfigurator_0.1.0.200710301724.jar/"
  by thread "main".

  - maybe I just happened to pick two bad versions?
Oleg Besedin | 1 Nov 16:43
Picon
Gravatar

Re: [sec] questions about EE for security


I agree, we certainly should use Import-Package. And, from what I understand, Scott is correct, the intention is to have Foundation 1.1 as a minimum execution environment for those bundles.

From a practical side, I just tried J9 (http://wiki.eclipse.org/J9) and from a quick glance things like javax.security.auth.Subject are, indeed, not present there. I think we'll need to find at least one Foundation 1.1 VM that has those packages (or can accept them as a separate download?) to claim 1.1 as a minimum execution environment.

Thanks,
Oleg




Thomas Watson <tjwatson-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
Sent by: equinox-dev-bounces-j9T/66MeVpFAfugRpC6u6w@public.gmane.org

11/01/2007 09:28 AM

Please respond to
Equinox development mailing list <equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org>

To
Equinox development mailing list <equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org>
cc
Subject
Re: [equinox-dev] [sec] questions about EE for security





Both John and Rem are correct.

Bundles which want to run on a smaller EE than J2SE-1.4 and have access to the javax.security.auth packages should use import-package (e.g. Import-Package: javax.security.auth). You should not make J2SE-1.4 your required EE only because other bundles you depend on use the EE.

Equinox is a broad community. A large number of our bundles do run on Foundation 1.1/1.0 (and even down to the minimum OSGi EE). But there are some extra features which require higher EEs. Currently parts of the security work in the incubator can only run on J2SE-1.4 or higher. For example, the core extension bundles (org.eclipse.equinox.security.boot.jre14x or org.eclipse.equinox.security.boot.jre15x) are installed into the extension classloader of the VM. This is required because we need to make the our security provider available to the VM and it will only search for providers on the boot classpath or the extension class loader. Unfortunately at that level the code will only have access to classes that are provided by the EE. They do not have the option to import additional packages which may come from other bundles installed in a Framework running on Foundation 1.1 EE.

I opened a couple of bugs against the security bundles. All Equinox bundles should use Import-Package to access packages outside the java.* namespace. We could also split some of the bundles to allow parts of it to run on a Foundation EE.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=208399
https://bugs.eclipse.org/bugs/show_bug.cgi?id=208400

Tom



John Arthorne ---10/31/2007 09:30:11 PM---I think the right approach is to set your bundle's EE to reflect the EE dependencies of *your* bundle, and not the bundles you

From:

John Arthorne <John_Arthorne-G1DYhSM1WHTQT0dZR+AlfA@public.gmane.org>

To:

Equinox development mailing list <equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org>

Date:

10/31/2007 09:30 PM

Subject:

Re: [equinox-dev] [sec] questions about EE for security





I think the right approach is to set your bundle's EE to reflect the EE dependencies of *your* bundle, and not the bundles you depend on. I.e., if your bundle doesn't directly depend on 1.4, you could still specify an EE of Foundation 1.1 for your bundle. If it turns out that the JAAS bundle requires 1.4, then your bundle will transitively fail to resolve anyway. That way you're not building assumptions into your bundle about the EE of downstream bundles that may change in the future.

John

Scott Lewis <slewis-moQcexxCXgLby3iVrkZq2A@public.gmane.org>
Sent by: equinox-dev-bounces-j9T/66MeVpFAfugRpC6u6w@public.gmane.org

10/31/2007 05:53 PM

Please respond to
Equinox development mailing list <equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org>


To
Equinox development mailing list <equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org>
cc
Subject
[equinox-dev] [sec] questions about EE for security







Hi Folks,

Some questions:  I thought I understood (from Equinox Summit) that the
recently approved minimum EE for Equinox 3.4 (Ganymede) was CDC
1.1/Foundation 1.1.

I see from looking at the equinox JAAS integration bundles (e.g.
org.eclipse.equinox.security.auth) that the runtime environment minimum
for those bundles is set to JRE 1.4.  I understand this, as the JAAS
work depends upon packages like javax.security.auth, and
javax.security.auth.login, etc.  which do not seem to be in CDC
1.1/Foundation 1.1.

So maybe I just answered my own question:  it seems that the JAAS
security bundles/plugins must assume JRE 1.4 (and can't/won't run on CDC
1.1/Foundation 1.1).  So the implicit (to me anyway) idea here is that
bundles that use/extend/depend upon the JAAS security integration also
obviously must assume JRE 1.4 and not just CDC 1.1.  Correct?

Scott


_______________________________________________
equinox-dev mailing list
equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev-j9T/66MeVpFAfugRpC6u6w@public.gmane.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Susan M Franklin | 1 Nov 18:15
Picon
Favicon
Gravatar

[prov] M3 docs and screen snaps


I'm updating the doc and screen snaps of the agent UI in the getting started and admin UI guides on the wiki.  
My working assumption is that the shipped agent won't have any repos set up initially.  And I'm using the testUpdates server in the example...
So someone let me know (or change the doc) if this ends up being different...

susan

Gmane