As part of migration to Beta2, this problem came up again. The support for
nonServiceProxies disappeared, and our services broke. I managed to find
the solution with help from Chris Daly.

The answer is that our XService extended TeamRawService, and implemented
IXService. IXService needs to extend ITeamRestService (and did not). In
addition, the common plugin where IXService is declared now has a dependence
on the javax.servlet plugin. Although it builds fine without the dependence
declared in the manifest, with the declared dependence on the
ITeamRestService and no javax.service, our service becomes entirely
unavailable (it is not even listed in the list of available services). Must
be some runtime reflection game going on.


"fmcgrath" <fmcgrath@us.ibm.com> wrote in message
news:fhfplb$v44$1@localhost.localdomain...

Just a ping, hoping for feedback.


"Chris Daly" <cjdaly@us.ibm.com> wrote in message
news:fg5duu$hfv$1@localhost.localdomain...
fmcgrath wrote:
...
I tried adding our service interface to the nonServiceProxies list and
it did resolve the issue. We are changing the setting in
teamserver.properties and on the command-line for jetty execution.

I am completely unclear on the meaning or intent of nonServiceProxies,
and am happy to try to arrange our service "the right way".


Matt mentioned that nonServiceProxies is going away in M4.

Can anyone provide more information about what nonServiceProxies is
doing? It seems like nonServiceProxies is allowing services to
temporarily get away with some behavior that we want to disallow, but
it's not clear what that is or how to rewrite the service the "correct"
way.

Just a ping, hoping for feedback.


"Chris Daly" <cjdaly@us.ibm.com> wrote in message
news:fg5duu$hfv$1@localhost.localdomain...

fmcgrath wrote:
...
I tried adding our service interface to the nonServiceProxies list and it
did resolve the issue. We are changing the setting in
teamserver.properties and on the command-line for jetty execution.

I am completely unclear on the meaning or intent of nonServiceProxies,
and am happy to try to arrange our service "the right way".


Matt mentioned that nonServiceProxies is going away in M4.

Can anyone provide more information about what nonServiceProxies is doing?
It seems like nonServiceProxies is allowing services to temporarily get
away with some behavior that we want to disallow, but it's not clear what
that is or how to rewrite the service the "correct" way.

The interface in question is used for file upload, and is a RAW_HTTP
service. It is currently used only from browser/javascript code to upload
files. The service implements TeamRawService. It was created by following
the pattern in a tutorial, and so the interface was in the service plugin.
Oddly, the extension was defined in our common plugin. I fixed this so that
the interface was in the common plugin.

I found (by debugging, there were no useful diagnostics that I could see)
that the service was still being deactivated when the plugin was first
loaded. Along the path to this deactivation, I saw the query about
nonServiceProxies. Jazz itself has a service
(com.ibm.team.workitem.common.internal.rest.IAttachmentRestService) that is
very similar to our service. IAttachmentRestService was listed in
teamserver.properties under nonServiceProxies, so I tried adding our service
interface to the nonServiceProxies list and it did resolve the issue. We
are changing the setting in teamserver.properties and on the command-line
for jetty execution.

I am completely unclear on the meaning or intent of nonServiceProxies, and
am happy to try to arrange our service "the right way".


"lavinm" <matt_lavin@us.ibm-dot-com.no-spam.invalid> wrote in message
news:fg4jkg$5ot$1@localhost.localdomain...

Could you provide a little more detail about what you did to fix the
problem?

First, What exactly did you do with the
"com.ibm.team.repository.service.nonServiceProxies"
property? That property is going away and will not be supported in
M4, as it was only there to support the transition to our new (new in
M3) framework for older services. New services should not modify, or
even know about, that property.

Second, you mention that the service interface was in the services
plugin, but it was declared in the common plugin. That is fine, and
maybe even the right thing to do, depending on what kind of service
you have. What interface is your service implementing? The the
service interface is used directly by the Java code on the client
then it should be in the common plugin, but if you have written a
REST service then the service interface should stay in the service
plugin.

Third, I don't quite follow your explanation of what happened before
you made the changes. If the service was deactivated, then it should
be fine for the service to be activated again. Perhaps when you
respond the details for my first and second questions I can try to
reproduce the problem and see what happened.


OK, I managed to get this to work again. There were two significant
changes
(I believe). The first was that our service interface was defined
to be
part of our service plugin, even though the service was declared in
the
plugin.xml from the common plugin. This was a remaining oddity from
the way
we created the original plugin based on one of the simple tutorials.
The
other significant change was to add a seeting for
-Dcom.ibm.team.repository.service.nonServiceProxies=
referencing my plugin to the launcher and to the
teamserver.properties.

On a related note; the initial symptoms were confused in the way
jazz
handled the problems. Initially, as the plugin loaded, the
extensions were
visited. When the service extension failed (because of the problems
listed
above) the service was listed as deactivated. Later, when the
service was
invoked explicitly later, the code in

com.ibm.team.repository.common.transport.internal.registry.AbstactActivationManagerOwner.forceActivate()

did not handle the problem; it did not consider that the service was
already
deactivated, and tried to activate it for the first time. This got
confused
because the referenced services were already connected, and the code
reacted
as if the services were being referenced multiple times from the
service.

"Chris Daly" <cjdaly@us.ibm.com> wrote in message
news:fflpgk$m8t$1@localhost.localdomain...

fmcgrath wrote:
In M2A we were able to upload files from a browser to a jazz server. In
M3A, we are now getting errors.

We debugged the problem and found Jazz enhanced the request checking in
the "com.ibm.team.repository.servlet.AbstractTeamServerServlet.doPost".

We see WARN .team.repository.servlet.AbstractTeamServerServlet -
Marshalling exception processing request for service
com.ibm.rational.test.lm.service.IXmlImportService:
org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Content is
not allowed in prolog.


Any ideas how to upload files.

What type of service is this (Rest, ModeledRest, ?)? Can you show your
service interface?

You might want to try paring your code down to a simple test case and then
file a defect with the test case.

OK, I managed to get this to work again. There were two significant changes
(I believe). The first was that our service interface was defined to be
part of our service plugin, even though the service was declared in the
plugin.xml from the common plugin. This was a remaining oddity from the way
we created the original plugin based on one of the simple tutorials. The
other significant change was to add a seeting for
-Dcom.ibm.team.repository.service.nonServiceProxies=
referencing my plugin to the launcher and to the teamserver.properties.

On a related note; the initial symptoms were confused in the way jazz
handled the problems. Initially, as the plugin loaded, the extensions were
visited. When the service extension failed (because of the problems listed
above) the service was listed as deactivated. Later, when the service was
invoked explicitly later, the code in
com.ibm.team.repository.common.transport.internal.registry.AbstactActivationManagerOwner.forceActivate()
did not handle the problem; it did not consider that the service was already
deactivated, and tried to activate it for the first time. This got confused
because the referenced services were already connected, and the code reacted
as if the services were being referenced multiple times from the service.