[WSIT-1670] webservices-osgi should not require IBM JDK classes Created: 15/May/13  Updated: 06/Sep/13  Resolved: 06/Sep/13

Status: Resolved
Project: wsit
Component/s: build, wsit-runtime
Affects Version/s: 2.2.1-1
Fix Version/s: 2.3.1

Type: Bug Priority: Major
Reporter: atrajano Assignee: Martin Grebac
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: osgi

 Description   

When trying to run in Karaf, I noticed that the MANIFEST.MF is requiring com.ibm.security.util,com.ibm.security.x509 which are not standard classes available in all JDKs. These should be made optional.



 Comments   
Comment by Martin Grebac [ 06/Sep/13 ]

Fixed in trunk:
commit -m "Fix of JAXWS-1117 - Optionally import IBM JDK classes." /Users/snajper/work/sources/wsit~svn/trunk/bundles/webservices-osgi/pom.xml
Sending /Users/snajper/work/sources/wsit~svn/trunk/bundles/webservices-osgi/pom.xml
Transmitting file data ...
Committed revision 7706.
Revision: 7706
Author : snajper
Date : Sep 6, 2013 5:24:02 PM
Fix of JAXWS-1117 - Optionally import IBM JDK classes.





[UNITSOFMEASUREMENT-134] Updating pom file(s) to use latest felix plugin Created: 29/May/15  Updated: 29/May/15

Status: Open
Project: unitsofmeasurement
Component/s: API, RI, TCK
Affects Version/s: 0.7.1
Fix Version/s: 0.8

Type: Task Priority: Major
Reporter: keilw Assignee: keilw
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: Maven, osgi
Epic Link: Infrastructure
Sprint: Q2/15

 Description   

As seen in https://issues.jboss.org/browse/CDI-509 for CDI 2 EDR 1, there's a new Apache Felix plugin version. We should leverage that, and while version numbers of individual packages are probably not so different in our case, also adjust OSGi export-package similar to:

<Export-Package>  			
                javax.decorator;version=1.1,  			
                javax.enterprise.*;version=1.1,  				
                javax.decorator;version=2.0,  
                [...]
</Export-Package>  





[MQ-328] Java Client - OSGI module layer support Created: 07/Aug/13  Updated: 07/Aug/13

Status: Open
Project: mq
Component/s: None
Affects Version/s: current
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Andrew_Scully Assignee: Ed Bratt
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Glassfish


Tags: bundle, maven, mq, osgi

 Description   

The OpenMQ jars (imq.jar, imqbroker.jar, etc.) are not bundles (they do not include OSGI metadata in their manifests).

It is therefore difficult to make use of the Java client code from within an OSGI project because of this, as the com.sun.messaging packages cannot be resolved by the OSGI framework (Apache Felix) at runtime.

The standard solution would be to "repackage" the jars as bundles, using the maven bundle plugin. Even this is difficult, however, as the jars are no longer available separately on maven central. Post 4.5.2, a zip (mq-distribution) is instead provided making it hard to declare dependencies on the particular projects your require.

The lack of OSGI metadata seems to be in contrast to the other Glassfish sub-projects (e.g shoal, grizzly), so it can come as a surprise to the unsuspecting developer.






[JPA_SPEC-60] Upload official/standard JPA 2.1 API jar to Maven Central Created: 13/Jun/13  Updated: 07/Feb/14  Due: 22/May/13

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Matthew Adams Assignee: Unassigned
Resolution: Unresolved Votes: 24
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: maven, osgi, repositories

 Description   

There is no official or standard JPA API jar available from the expert group in either Maven Central or the java.net Maven repo that both JPA users & implementors can utilize. Users are left to search for implementations' groupId, artifactId, & version values, which is inconvenient.

Please upload a binary jar (including class files and relevant resource files), a source jar, and a javadoc jar, under the groupId "javax.persistence", artifact id "jpa-api" and version "2.1". A minimal target Maven repository would be Maven Central, but others like java.net might be nice, too.

Bonus points for including OSGi bundle metadata (pretty easy if using Apache Felix's Maven Bundle Plugin, org.apache.felix:maven-bundle-plugin:2.3.7)!



 Comments   
Comment by Matthew Adams [ 13/Jun/13 ]

This issue is the same as https://java.net/jira/browse/JPA_SPEC-19 except for JPA 2.1.

Comment by datanucleus [ 13/Jun/13 ]

Since when has an implementation had to provide their own variant of the "standard" API jar? Such a basic thing ought to be a prerequisite of the JSR to have that as one of its deliverables and the JSR not considered "complete" til its done, just like the spec and TCK (and add to that publishing of XSD/DTDs on a public site). Or maybe its just another way to keep it all "secret" (like that mystical TCK) ...

Comment by Matthew Adams [ 13/Jun/13 ]

http://search.maven.org/#artifactdetails%7Cjavax%7Cjavaee-api%7C7.0%7Cjar

Is this intended to be the release? If so, it might do for some, but a standalone JPA API artifact would be ideal.

Comment by neilstockton [ 14/Nov/13 ]

Seems like voting on this JIRA is not looked at by the people behind JPA, evidently not interested in what the majority of people want.

Comment by Oliver Gierke [ 07/Feb/14 ]

I'd also like to vote to finally introduce a canonical API JAR. We're currently seeing a lot of users running into classpath issues for the following reasons:

Persistence providers historically shipped their own packaged API versions. For libraries trying to build on top of JPA this created the unfortunate situation that they had to refer to a persistence provider provided API JAR which subverts the provider independence of the library.

Even worse, as the providers get access to the API JARs in different versions they do not use the specification version as artifact version but incorporate the spec version in the artifact id. E.g. for Hibernate, the API JAR has the following coordinates:

2.0 - org.hibernate.javax.persistence:hibernate-jpa-2.0-api:1.0.1.Final
2.1 - org.hibernate.javax.persistence:hibernate-jpa-2.1-api:1.0.0.Final

Note, that these two do not represent a single artifact in different versions but two completely separate artifacts. Hence, dependency management systems will not be able to apply version conflict resolution to those and users are very likely to accidentally get both JARs into their classpath and then spend a lot of time debugging ClassNotFoundExceptions for their JPA 2.1 provider that might see the 2.0 JAR first.

Long story short, this is way more tedious than it needs to be. Releasing a canonical API JAR would solve these issues.

P.S.: No, a 1.8 MB JavaEE 7 API JAR is probably not what you want to pull into an application or library that depends on JPA only.





[JPA_SPEC-19] Upload official/standard JPA 2.0 API jar to Maven Central Created: 05/Apr/12  Updated: 13/Jun/13

Status: Open
Project: jpa-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: Matthew Adams Assignee: ldemichiel
Resolution: Unresolved Votes: 13
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: bundle, maven, mavenization, osgi, repositories, repository

 Description   

There is no official or standard JPA API jar available from the expert group in either Maven Central or the java.net Maven repo that both JPA users & implementors can utilize. Users are left to search for implementations' groupId, artifactId, & version values, which is inconvenient.

Please upload a binary jar (including class files and relevant resource files), a source jar, and a javadoc jar, under the groupId "javax.persistence", artifact id "jpa-api" and version "2.0". A minimal target Maven repository would be Maven Central, but others like java.net might be nice, too.

Bonus points for including OSGi bundle metadata (pretty easy if using Apache Felix's Maven Bundle Plugin, org.apache.felix:maven-bundle-plugin:2.3.7)!



 Comments   
Comment by Matthew Adams [ 13/Jun/13 ]

http://search.maven.org/#artifactdetails%7Cjavax%7Cjavaee-api%7C6.0%7Cjar

Is this intended to be the release? If so, it might do for some, but a standalone JPA API artifact would be ideal.





[JERSEY-2819] ServletContainer hangs on startup - infinite loop Created: 10/Mar/15  Updated: 29/May/15  Resolved: 29/May/15

Status: Resolved
Project: jersey
Component/s: core, osgi
Affects Version/s: 2.16
Fix Version/s: 2.18

Type: Bug Priority: Major
Reporter: vdjurovic Assignee: Stepan Vavra
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Jetty 9.2.9.v20150224 running inside Apache Felix 4.4.2 OSGI container


Attachments: Zip Archive jersey-startup-freeze.zip    
Tags: osgi

 Description   

I'm trying to deploy simple web app to Jetty runnin inside OSGI container. What I am experiencing in that ServletContainer hangs on startup and never loads.
My web.xml:

 <servlet>
        <servlet-name>Jersey Web Application</servlet-name>
        <servlet-class>org.glassfish.jersey.servlet.ServletContainer</servlet-class>
        <init-param>
            <param-name>jersey.config.server.provider.packages</param-name>
            <param-value>com.vektorsoft.demux.web.resource</param-value>
        </init-param>
        
        <load-on-startup>10</load-on-startup>
    </servlet>
    <servlet-mapping>
        <servlet-name>Jersey Web Application</servlet-name>
        <url-pattern>/webresources/*</url-pattern>
    </servlet-mapping>

I managed to isolate infinite loop happenning in org.glassfish.jersey.server.ResourceConfig, lines 887-905. The reason is that _org.glassfish.server.internal.scanning.BundleSchemeResourceFinderFactory.next() method does not advance iteration, but always returns the same item. Advance happens only in open() method in that class.

So, when you specify package which contains subpacakges as jersey.config.server.provider.packages property, infinite loop will happen. The reason is tha package name is never accepted in ResourceConfig:890, so open() is never called in _BundleSchemeResourceFInderFactory and iteration does not advance, returning the same object over and voer again.

If you specify package that does not contain subpackages as jersey.config.server.provider.packages, everything works fine.



 Comments   
Comment by Adam Lindenthal [ 11/Mar/15 ]

Hi Vdjurovic,

thanks for reporting and for investigation you've made.

Could you please make it easier for us to reproduce by providing a minimal test case (the configuration you've provided + e.g. one resource) and most importantly some steps to do? We do not run jetty inside osgi on our tests. Is this achievable within maven using some plugins (pax exam, etc)? It would be also useful for creating some integration test after its fixed.

It would be very helpful if you could write down some steps like "start the felix shell", "write [whatever command] to load [such and such] bundle", etc.

Many thanks,
Adam

Comment by Adam Lindenthal [ 11/Mar/15 ]

In the meantime, I will move this issue to backlog for further planning.

Comment by vdjurovic [ 11/Mar/15 ]

Hi, Adam

I've just started working on this project yesterday (and hit this bump immediatelly ), so I can not really provide streamlined test case. I have created Maven project with 3 modules:

  • server - Jetty server running inside Apace Felix
  • simple-bundle - OSGI bundle containing JAX-RS resources
  • jersey-startup-freeze-war - web application which starts ServletContainer

I can't attach files, so here is the download link:http://vektorsoft.com/files/jersey-startup-freeze.zip

How to run:

  1. extract the contents and change to jersey-startup-freeze dir
  2. run mvn install
  3. cd to server dir
  4. run
    java -Djetty.home=jettyhome/ -jar bin/felix.jar
  5. web app should start few seconds after server startup and freeze immediatelly. It also causes entire server to freeze
  6. in web.xml, if you change jersey.config.server.provider.packages value to package without subpackages, app starts normally

To run server in debug mode, use this command:

ava -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=<port_number> -Djetty.home=jettyhome/ -jar bin/felix.jar

Then attach debugger. If you set breakpoint to the line I've specified in bug descritpion, you can see infinite loop is created.

I'm not sure about running integration tests, Pax Exam is probably good choice. I don't have much free time right now, but I can try to set something up later when I'm not too busy.
Let me know if you need any more info from me.

Comment by Adam Lindenthal [ 11/Mar/15 ]

Thanks a lot, I guess that will be very helpful for reproducing. I've attached your zip here for the one of us who will be working on it.

Regards,
Adam

Comment by Stepan Vavra [ 29/May/15 ]

It should be fixed now!





[JERSEY-2243] Using Sse with Jersey in OSGi Created: 22/Nov/13  Updated: 25/Nov/13  Resolved: 25/Nov/13

Status: Resolved
Project: jersey
Component/s: media, osgi
Affects Version/s: 2.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: lifedj Assignee: Michal Gajdos
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7, Eclipse Kepler


Tags: JAX-RS, Jersey, OSGi, SSe

 Description   

I'm trying to implement a simple Java Sse server using Jersey on OSGi.
I've followed the example described in the Jersey official guide:

https://jersey.java.net/documentation/latest/sse.html#d0e8183

but when I try to call the server, it says: "MessageBodyWriter not found for media type=text/event-stream, type=class org.glassfish.jersey.media.sse.OutboundEvent, genericType=class org.glassfish.jersey.media.sse.OutboundEvent."

I've found some other similar issues in which all say to register SSE feature, but in OSGi there is not a main in which I can register it, and, moreover, the SseFeature doesn't provide any service!
How can i register the sse feature? Or: what can I do to fix the problem?

PS. To work in OSGi, Jersey need the connector:
https://github.com/hstaudacher/osgi-jax-rs-connector

Here I will paste the code you should need to help me!

MANIFEST.MF

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: RestServerSSE
Bundle-SymbolicName: it.prova.sse
Bundle-Version: 1.0.0.qualifier
Bundle-RequiredExecutionEnvironment: JavaSE-1.7
Import-Package: javax.ws.rs;version="2.0.0",
 javax.ws.rs.core;version="2.0.0",
 javax.ws.rs.ext;version="2.0.0",
 org.glassfish.jersey.media.sse;version="2.0.0",
 org.glassfish.jersey.message;version="2.0.0",
 org.glassfish.jersey.server;version="2.0.0",
 org.osgi.framework;version="1.7.0"
Service-Component: OSGI-INF/component.xml

component.xml

<?xml version="1.0" encoding="UTF-8"?>
<scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0" name="it.prova.sse">
   <implementation class="it.prova.sse.Server"/>
   <service>
      <provide interface="it.prova.sse.Server"/>
   </service>
</scr:component>

Server.java

package it.polito.server.rest.sse;
import java.io.IOException;
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.Produces;
import org.glassfish.jersey.media.sse.EventOutput;
import org.glassfish.jersey.media.sse.OutboundEvent;
import org.glassfish.jersey.media.sse.SseFeature;
import org.glassfish.jersey.server.ResourceConfig;

@Path("/sse")
public class Server
{
public Server()
{
    final ResourceConfig resourceConfig = new ResourceConfig(Server.class,SseFeature.class);
}
	
  @GET
    @Produces(SseFeature.SERVER_SENT_EVENTS)
      public EventOutput getServerSentEvents() {
		
        final EventOutput eventOutput = new EventOutput();
        new Thread(new Runnable() {
          @Override
            public void run() {
               try {
               for (int i = 0; i < 10; i++) {
               // ... code that waits 1 second
               final OutboundEvent.Builder eventBuilder
               = new OutboundEvent.Builder();
               eventBuilder.name("message-to-client");
                  eventBuilder.data(String.class,
                      "Hello world " + i + "!");
                      final OutboundEvent event = eventBuilder.build();
                      eventOutput.write(event);
                  }
               } catch (IOException e) {
                  throw new RuntimeException(
                      "Error when writing the event.", e);
               } finally {
                  try {
                      eventOutput.close();
                  } catch (IOException ioClose) {
                      throw new RuntimeException(
                          "Error when closing the event output.", ioClose);
                  }
              }
           }
        }).start();
        return eventOutput;
    }
}


 Comments   
Comment by Michal Gajdos [ 25/Nov/13 ]

This is not a bug. You're configuring wrong ResourceConfig. You should configure the one that is used during deployment time and not the one that you create in a resource (please consult documentation to osgi connector how to do that).





[JERSEY-1741] OSGiRegistry and Package Scanner fails with 2 or more WABs Created: 19/Feb/13  Updated: 20/Jan/14

Status: Open
Project: jersey
Component/s: core
Affects Version/s: 1.17
Fix Version/s: 1.x-backlog, backlog

Type: Bug Priority: Minor
Reporter: allen.lau Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: osgi

 Description   

When the Package Scanner mechanism is used in 2+ WABs in an OSGi environment, there is a race condition on initialization.

Looking at the OSGiRegistry source, the classToMappingBundle is called once for each WAB. If I have 2 WAB in the container, then only the last initialized WAB's services are visible.






[JERSEY-1547] Unable to create a client in an OSGi environment with blueprint: add OSGi Bleuprint container support Created: 31/Oct/12  Updated: 04/Nov/13

Status: Open
Project: jersey
Component/s: osgi
Affects Version/s: 2.0-m09
Fix Version/s: icebox

Type: New Feature Priority: Major
Reporter: atrajano Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Pax Exam, Aries Blueprint


Attachments: Zip Archive jersey-blueprint-sample.zip    
Tags: blueprint, client, osgi

 Description   

An example should resolve this issue or perhaps an Activator.

I have the tried to create the client using the following

<blueprint>

<!-- one of -->
<bean id="client" class="javax.ws.rs.client.ClientFactory" factory-method="newClient" />
<bean id="client" class="org.glassfish.jersey.client.JerseyClientFactory" factory-method="newClient" />
<bean id="client" class="org.glassfish.jersey.client.JerseyClientFactory" factory-method="getClient" />
<bean id="client" class="org.glassfish.jersey.client.JerseyClient" />
<bean id="client" class="my.package.ExposedJerseyClient" />

<service ref="client" interface="javax.ws.rs.client.Client" />
</blueprint>

Alas, no luck. I am getting LinkageError: ClassCastException on PAX Exam.

For examples, most of what I have seen are only for the server, I haven't found one that is OSGi and client.

I only plan to run the client, no server side.



 Comments   
Comment by Jakub Podlesak [ 07/Nov/12 ]

Could you please provide a small reproducible test case? Ideally a maven based project?

Comment by Jakub Podlesak [ 12/Nov/12 ]

I think this is more about adding a new feature ([1] integration) than fixing a bug in Jersey.
I have adjusted the issue type accordingly and slightly updated the issue title.

Please note that so far we have implemented support for OSGi HTTP Service feature
and support for OSGi WAB deployment.

It would be great if we could get a test case project attached to this issue report
as i have requested in the previous comment.

[1]http://static.springsource.org/osgi/docs/2.0.0.M1/reference/html/blueprint.html

Comment by atrajano [ 17/Nov/12 ]

This is an example jersey project with an associated unit test.

This will fail during the test when running mvn install on the main folder.

To "fix" the test, the jersey.xml needs to be modified to comment out the reference to creating a Jersey client





[JERSEY-1521] Jersey should stop using OSGi DynamicImport-Package: * header Created: 22/Oct/12  Updated: 20/Jan/14

Status: Open
Project: jersey
Component/s: None
Affects Version/s: backlog
Fix Version/s: icebox

Type: Improvement Priority: Major
Reporter: Jakub Podlesak Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks GLASSFISH-13165 Jersey uses DynamicImport-Package: * Open
Tags: osgi

 Description   

The dynamic import clause is to allow Jersey load application classes, which are included in packages, that can not be captured
in a more specific import clause (as application packages are not known at Jersey compile time).
To load these application classes in the OSGi environment, we should try to get rid of the dynamic import header and load the classes directly via OSGi APIs.






[JERSEY-1409] Extended WADL generation fail under OSGI Created: 06/Sep/12  Updated: 19/Nov/12  Resolved: 12/Nov/12

Status: Resolved
Project: jersey
Component/s: osgi
Affects Version/s: 1.13
Fix Version/s: 2.0-m10, 2.0

Type: Bug Priority: Major
Reporter: Mikhail Mazursky Assignee: Jakub Podlesak
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 10 hours
Original Estimate: Not Specified
Environment:

Linux, Equinox 3.7, OpenJDK 1.7.0_03


Tags: classloader, osgi, wadl

 Description   

Using code based on [1]:

@Override
public List<WadlGeneratorDescription> configure() {
	return generator(WadlGeneratorResourceDocSupport.class).prop("resourceDocStream", "resourcedoc.xml").descriptions();
}

i get the following stacktrace:

java.lang.RuntimeException: Could not load wadl generators from wadlGeneratorDescriptions.
        at com.sun.jersey.api.wadl.config.WadlGeneratorConfig.createWadlGenerator(WadlGeneratorConfig.java:184) ~[na:na]
        at com.sun.jersey.server.impl.wadl.WadlApplicationContextImpl.<init>(WadlApplicationContextImpl.java:92) ~[na:na]
        at com.sun.jersey.server.impl.wadl.WadlFactory.init(WadlFactory.java:96) ~[na:na]
        at com.sun.jersey.server.impl.application.RootResourceUriRules.initWadl(RootResourceUriRules.java:169) ~[na:na]
        at com.sun.jersey.server.impl.application.RootResourceUriRules.<init>(RootResourceUriRules.java:106) ~[na:na]
        at com.sun.jersey.server.impl.application.WebApplicationImpl._initiate(WebApplicationImpl.java:1300) ~[na:na]
        at com.sun.jersey.server.impl.application.WebApplicationImpl.access$700(WebApplicationImpl.java:163) ~[na:na]
        at com.sun.jersey.server.impl.application.WebApplicationImpl$13.f(WebApplicationImpl.java:769) ~[na:na]
        at com.sun.jersey.server.impl.application.WebApplicationImpl$13.f(WebApplicationImpl.java:765) ~[na:na]
        at com.sun.jersey.spi.inject.Errors.processWithErrors(Errors.java:193) ~[na:na]
        at com.sun.jersey.server.impl.application.WebApplicationImpl.initiate(WebApplicationImpl.java:765) ~[na:na]
        at com.sun.jersey.guice.spi.container.servlet.GuiceContainer.initiate(GuiceContainer.java:121) ~[na:na]
        at com.sun.jersey.spi.container.servlet.ServletContainer$InternalWebComponent.initiate(ServletContainer.java:319) ~[na:na]
        at com.sun.jersey.spi.container.servlet.WebComponent.load(WebComponent.java:609) ~[na:na]
        at com.sun.jersey.spi.container.servlet.WebComponent.init(WebComponent.java:210) ~[na:na]
        at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:374) ~[na:na]
        at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:557) ~[na:na]
        [snip]
Caused by: java.lang.RuntimeException: The resource 'resourcedoc.xml' does not exist.
        at com.sun.jersey.api.wadl.config.WadlGeneratorLoader.setProperty(WadlGeneratorLoader.java:203) ~[na:na]
        at com.sun.jersey.api.wadl.config.WadlGeneratorLoader.loadWadlGenerator(WadlGeneratorLoader.java:139) ~[na:na]
        at com.sun.jersey.api.wadl.config.WadlGeneratorLoader.loadWadlGeneratorDescriptions(WadlGeneratorLoader.java:114) ~[na:na]
        at com.sun.jersey.api.wadl.config.WadlGeneratorConfig.createWadlGenerator(WadlGeneratorConfig.java:182) ~[na:na]
        ... 66 common frames omitted

The same code works perfectly if used outside of OSGI (under Grizzly).

[1]: https://wikis.oracle.com/display/Jersey/HowToConfigureExtendedWADL



 Comments   
Comment by Mikhail Mazursky [ 06/Sep/12 ]

The problem is in com.sun.jersey.api.wadl.config.WadlGeneratorLoader.setProperty() that uses wrong (for OSGI) classloader:

final String resource = propertyValue.toString();
ClassLoader loader = Thread.currentThread().getContextClassLoader();
if (loader == null) {
    loader = WadlGeneratorLoader.class.getClassLoader();
}
final InputStream is = loader.getResourceAsStream(resource);
if (is == null) {
    String message = "The resource '" + resource + "' does not exist.";
    throw new RuntimeException(message);
}

I see some possible workarounds/fixes:

  • Somehow pass a Classloader to use to load specified resource;
  • Improve parameter passing to property method so that InputStream can be passed - i tried to load the resource myself, then pass it's contents as ByteArrayInputStream to the .prop("resourceDocStream", bais) but it fails because of a too strick type check:
    final Class<?> paramClazz = method.getParameterTypes()[0];
    if (paramClazz == propertyValue.getClass()) {
        method.invoke(generator, propertyValue);
    

    I propose to change this code to:

    final Class<?> paramClazz = method.getParameterTypes()[0];
    -- if (paramClazz == propertyValue.getClass()) {
    ++ if (paramClazz.isAssignableFrom(propertyValue.getClass())) {
        method.invoke(generator, propertyValue);
    

    This also looks like the right thing to do anyway.

  • Add WadlGeneratorResourceDocSupport.setResourceDocArray(byte[]) so that resource contents can be passed directly (this is not relevant if the previous fix is implemented).

p.s. looks like a possible NPE in

if (loader == null) {
    loader = WadlGeneratorLoader.class.getClassLoader();
}
final InputStream is = loader.getResourceAsStream(resource);

because .getClassLoader() can return null.

Comment by Jakub Podlesak [ 27/Sep/12 ]

Do you have a reproducible test case handy that you could attach to this report? That would help us a lot to speed up fixing this. Thanks for understanding!

Comment by Mikhail Mazursky [ 06/Oct/12 ]

You may take a look at this sample [1]. It reproduces the problem, but i failed to make it work for non-extended WADL too. It have some weird OSGi-related problem that my original setup do not have. You can launch it using the provided instructions on the page. It seems that due to some Jetty-related issue you have to stop/start the application from the console using:
stop com.ash2k.example.osgi-wadl
start com.ash2k.example.osgi-wadl

Hope that helps.

[1]: https://github.com/ash2k/osgi-jetty-playground

Comment by Jakub Podlesak [ 15/Oct/12 ]

Thanks! I am now able to reproduce.

Comment by Jakub Podlesak [ 24/Oct/12 ]

Going to relax the parameter check as suggested above so that you can pass an InputStream in.
Please keep in mind that in OSGi environment, you would need to get the input stream via OSGi API, e.g. like follows:

InputStream resourceStream = FrameworkUtil.getBundle(this.getClass()).getEntry(RESOURCEDOC_FILE).openStream();

If there is demand we might want to wire better OSGi support directly into the Jersey WADL codebase,
but that would not be doable in 1.15 timeframe.

Comment by Jakub Podlesak [ 24/Oct/12 ]

Fixed in the main trunk:

Sending changes.txt
Sending jersey-server/src/main/java/com/sun/jersey/api/wadl/config/WadlGeneratorLoader.java
Transmitting file data ..
Committed revision 5797.

Comment by Jakub Podlesak [ 09/Nov/12 ]

Re-opening to be able to implement a better fix. It should not be required to pass an input stream in.

Comment by Jakub Podlesak [ 12/Nov/12 ]

Jersey 1 codebase left intact, but applied a fix to Jersey 2 codebase, where you should not need to provide an input stream directly,
if required resource files are located in the very same bundle as the WadlGeneratorConfigurator class itself.
Added a test case to the extended wadl webapp example.





[JERSEY-927] Package name resource config does not work in OSGi environment Created: 26/Jan/12  Updated: 08/Aug/13  Resolved: 27/Jan/12

Status: Resolved
Project: jersey
Component/s: core
Affects Version/s: 1.8
Fix Version/s: 1.17

Type: Bug Priority: Major
Reporter: saikirandaripelli Assignee: Jakub Podlesak
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates JERSEY-881 Package name resource config does not... Resolved
Tags: osgi

 Description   

I am not able to run Jersey OSGI WAB with PackagenamesResourceConfig in Apache Felix or Equinox.
I tried in jersey 1.8, 1.9 and 1.10.

<init-param>
<param-name>com.sun.jersey.config.property.resourceConfigClass</param-name>
<param-value>com.sun.jersey.api.core.PackagesResourceConfig</param-value>
</init-param>
<init-param>
<param-name>com.sun.jersey.config.property.packages</param-name>
<param-value>com.sun.jersey.samples.helloworld</param-value>
</init-param>



 Comments   
Comment by saikirandaripelli [ 26/Jan/12 ]

Steps to Reproduce:

1. Download sample osgi app from https://maven.java.net/service/local/artifact/maven/redirect?r=releases&g=com.sun.jersey.samples&a=helloworld-osgi-webapp&v=1.11&c=project&e=zip

2. un-zip it.

3. open helloworld-osgi-webapp-1.11/war-bundle/src/main/webapp/WEB-INF/web.xml

4. replace the init-params of "Jersey Web Application" servlet with one specified n Jira description.

5. Follow /helloworld-osgi-webapp-1.11/README.html and deploy it to Felix or Equinox and try to access the resource.

Comment by Pavel Bucek [ 27/Jan/12 ]

duplicate of http://java.net/jira/browse/JERSEY-881

Comment by Pavel Bucek [ 27/Jan/12 ]

duplicate





[JAVOLUTION-114] Default logging produces output on stdout, with no way to silence debug logging Created: 25/Jan/14  Updated: 25/Jan/14

Status: Open
Project: javolution
Component/s: None
Affects Version/s: current
Fix Version/s: None

Type: Bug Priority: Major
Reporter: jdstroy Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

jdk1.7.0_51
Windows 2008 R2
AMD64


Tags: context, default, logging, osgi

 Description   

Javolution 6.0.0 defaults to DEBUG level logging for LogContext. Outside of an OSGi container, the default logging mechanism for Javolution produces output on stdout. When the logging level or LogContext is changed, log messages are generated because of the default level being set to DEBUG. Even changing the Configurable<Level> named LEVEL in LogContext produces output.

Unfortunately, this means that outside of an OSGi container, there isn't a way to change the log level of Javolution without producing debug messages on stdout. This interferes with applications that use Javolution in a pipeline manner, consuming input from stdin and writing data to stdout.

Possible resolutions to this can be to change the default logging output to stderr, or change the default logging level to a level which doesn't emit messages when the logging level is changed (anything lower than DEBUG).



 Comments   
Comment by jdstroy [ 25/Jan/14 ]

This appears to have been fixed in trunk (r217) by defaulting to INFO instead of DEBUG. 6.1.0 doesn't appear in Central, though.





[JAVAMONEY-105] Moneta not building as Bundle Created: 13/May/15  Updated: 14/May/15  Resolved: 14/May/15

Status: Resolved
Project: javamoney
Component/s: Impl: RI
Affects Version/s: 1.0.1
Fix Version/s: 1.0.1

Type: Bug Priority: Major
Reporter: keilw Assignee: keilw
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: Maven, osgi

 Description   

Moneta after switching to 1.0.1-SNAPSHOT would no longer build as (OSGi) "bundle". So I briefly adjusted the POM to <packaging>jar</packaging>.
This is a temporary workaround, and since OSGi will become even more important for Java 9 and Jigsaw (the two are supposed to be compatible in some way) plus every OSGi container (Eclipse, Apache,...) relies on a proper bundle signature of not just the API but all artifacts, this must be resolved before 1.0.1 can be wrapped-up.

Strangely it works perfectly well for moneta-bp meaning, their POMs must differ not just for the JVM or artifactIds...



 Comments   
Comment by otaviojava [ 13/May/15 ]

The fact the OpenJDK explore OSGI as study doesn't mean it will use the same behavior of OSGI.
http://openjdk.java.net/projects/penrose/
http://openjdk.java.net/projects/jigsaw/
The fact of the project doesn't run without OSGI not means it will not run with JIGSAWS.
So it isn't high priority.

Comment by keilw [ 13/May/15 ]

Regardless Moneta must continue what 1.0 already provided. That version was fully OSGi compliant, so the likes of Spring/Pivotal or others don't have to do this themselves (with those weird "com.springsource.log4j" or similar bundles ) We care about Jigsaw modularization of the RI when the time comes. If you find a Java 9 preview version stable and reliable enough, feel free to test it, but in a separate branch/fork please.

Comment by keilw [ 14/May/15 ]

Applied proper bundle plugin config





[JAUDIOTAGGER-440] Generate OSGi MANIFEST.MF headers in the build Created: 15/Aug/12  Updated: 14/Jan/15  Resolved: 14/Jan/15

Status: Closed
Project: jaudiotagger
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: elstensoftware Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: JAR, build, osgi

 Description   

When JAT is build into a JAR, it would be good if the MANIFEST.MF generated inside the JAR could include OSGi headers. This makes JAT an OSGi 'bundle' and suitable for deployment into an OSGi container.

This gives a number of benefits:

  • Easy deployment for existing users of OSGi containers
  • Capability to modularise code better an disallow access to certain packages
  • Able to run multiple versions of JAT at once and have versions updated without restarting the VM

I ported bliss to the OSGi platform and as part of this I adapted JAT to be an OSGi bundle. My method and example MANIFEST.MF is documented here:

http://www.elstensoftware.com/blog/2012/08/15/osgi-jaudiotagger/

BTW, adding these headers to the MANIFEST doesn't affect 'vanilla' Java VMs using the same JAR.



 Comments   
Comment by paultaylor [ 01/Feb/13 ]

Hi Dan, if you can provide a full patch including modified pom for doing this all automatically from maven then Im happy to add it in.

Comment by paultaylor [ 14/Jan/15 ]

Moved to https://bitbucket.org/ijabz/jaudiotagger/issue/26/generate-osgi-manifestmf-headers-in-the





[HK2-125] osgiversion-maven-plugin sets property value to 0.0.0 for a maven version=12.1.3.332 Created: 17/Jul/13  Updated: 06/Dec/13  Resolved: 06/Dec/13

Status: Resolved
Project: hk2
Component/s: None
Affects Version/s: 2.2.0
Fix Version/s: 2.2.0

Type: Bug Priority: Critical
Reporter: Romain Grécourt Assignee: Romain Grécourt
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: maven, osgi

 Description   

When using a maven version = ww.x.y.z[z*], the osgiversion maven plugin set a property to 0.0.0.
This is not an expected behavior as the property is used then to version export/import in-house packages.

Looking at SemanticVersioning.pdf

    A version can consist of maximum 4 parts: major, minor, micro, and qualifier. The syntax is:
     version ::= <major> [ '.' <minor> [ '.' <micro> [ '.' <qualifier> ]]]

configuration of the plugin is the following:

                <configuration>
                    <dropVersionComponent>qualifier</dropVersionComponent>
                    <versionPropertyName>project.osgi.version</versionPropertyName>
                </configuration>


 Comments   
Comment by Romain Grécourt [ 18/Jul/13 ]

The following diff has been reviewed by Mason and pushed.

diff --git a/hk2/osgiversion-maven-plugin/src/main/java/com/sun/enterprise/module/maven/OsgiVersionMojo.java b/hk2/osgiversion-maven-plugin/src/main/java/com/sun/enterprise/module/maven/OsgiVersionMojo.java
index bb8cc39..a93f001 100644
--- a/hk2/osgiversion-maven-plugin/src/main/java/com/sun/enterprise/module/maven/OsgiVersionMojo.java
+++ b/hk2/osgiversion-maven-plugin/src/main/java/com/sun/enterprise/module/maven/OsgiVersionMojo.java
@@ -1,7 +1,7 @@
 /*
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS HEADER.
  *
- * Copyright (c) 2007-2011 Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 2007-2013 Oracle and/or its affiliates. All rights reserved.
  *
  * The contents of this file are subject to the terms of either the GNU
  * General Public License Version 2 only ("GPL") or the Common Development
@@ -40,12 +40,11 @@
 
 package com.sun.enterprise.module.maven;
 
+import org.glassfish.hk2.maven.Version;
 import org.apache.maven.plugin.AbstractMojo;
 import org.apache.maven.plugin.MojoExecutionException;
 import org.apache.maven.plugin.MojoFailureException;
 import org.apache.maven.project.MavenProject;
-import org.apache.maven.shared.osgi.Maven2OsgiConverter;
-import org.apache.maven.artifact.versioning.DefaultArtifactVersion;
 
 /**
  * Converts the project version into the OSGi format and
@@ -69,7 +68,7 @@ public class OsgiVersionMojo extends AbstractMojo {
      * @readonly
      */
     protected MavenProject project;
-
+    
     /**
      * Flag used to determine what components of the version will be used
      * in OSGi version.
@@ -87,55 +86,17 @@ public class OsgiVersionMojo extends AbstractMojo {
      * major, minor and micro portions will be used.
      * @parameter
      */
-    protected String dropVersionComponent;
+    protected Version.COMPONENT dropVersionComponent;
 
     /**
      * @parameter default-value="project.osgi.version"
      */
     protected String versionPropertyName;
 
-    private enum VERSION_COMPONENT {major, minor, micro, qualifier};
-
-    /**
-     * @component
-     */
-    protected Maven2OsgiConverter converter;
-
+    @Override
     public void execute() throws MojoExecutionException, MojoFailureException {
-        DefaultArtifactVersion projectVersion =
-                new DefaultArtifactVersion(project.getVersion());
-        VERSION_COMPONENT compToDrop = dropVersionComponent == null ?
-                null : VERSION_COMPONENT.valueOf(dropVersionComponent);
-
-        DefaultArtifactVersion newVersion = projectVersion;
-        if (compToDrop != null) {
-            switch (compToDrop) {
-                case major: {
-                    newVersion = new DefaultArtifactVersion("0.0.0");
-                    break;
-                }
-                case minor: {
-                    final int major = projectVersion.getMajorVersion();
-                    newVersion = new DefaultArtifactVersion(major +"");
-                    break;
-                }
-                case micro: {
-                    final int major = projectVersion.getMajorVersion();
-                    final int minor = projectVersion.getMinorVersion();
-                    newVersion = new DefaultArtifactVersion(major + "." + minor);
-                    break;
-                }
-                case qualifier: {
-                    final int major = projectVersion.getMajorVersion();
-                    final int minor = projectVersion.getMinorVersion();
-                    final int micro = projectVersion.getIncrementalVersion();
-                    newVersion = new DefaultArtifactVersion(major + "." + minor + "." + micro);
-                    break;
-                }
-            }
-        }
-        String v = converter.getVersion(newVersion.toString());
-
+        Version projectVersion = new Version(project.getVersion());
+        String v = projectVersion.convertToOsgi(dropVersionComponent);
         getLog().debug("OSGi Version for "+project.getVersion()+" is "+v);
         getLog().debug("It is set in project property called "+ versionPropertyName);
         project.getProperties().put(versionPropertyName,v);
diff --git a/hk2/osgiversion-maven-plugin/src/main/java/org/glassfish/hk2/maven/Version.java b/hk2/osgiversion-maven-plugin/src/main/java/org/glassfish/hk2/maven/Version.java
new file mode 100644
index 0000000..5b9cd84
--- /dev/null
+++ b/hk2/osgiversion-maven-plugin/src/main/java/org/glassfish/hk2/maven/Version.java
@@ -0,0 +1,167 @@
+/*
+ * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS HEADER.
+ *
+ * Copyright (c) 2013 Oracle and/or its affiliates. All rights reserved.
+ *
+ * The contents of this file are subject to the terms of either the GNU
+ * General Public License Version 2 only ("GPL") or the Common Development
+ * and Distribution License("CDDL") (collectively, the "License").  You
+ * may not use this file except in compliance with the License.  You can
+ * obtain a copy of the License at
+ * https://glassfish.dev.java.net/public/CDDL+GPL_1_1.html
+ * or packager/legal/LICENSE.txt.  See the License for the specific
+ * language governing permissions and limitations under the License.
+ *
+ * When distributing the software, include this License Header Notice in each
+ * file and include the License file at packager/legal/LICENSE.txt.
+ *
+ * GPL Classpath Exception:
+ * Oracle designates this particular file as subject to the "Classpath"
+ * exception as provided by Oracle in the GPL Version 2 section of the License
+ * file that accompanied this code.
+ *
+ * Modifications:
+ * If applicable, add the following below the License Header, with the fields
+ * enclosed by brackets [] replaced by your own identifying information:
+ * "Portions Copyright [year] [name of copyright owner]"
+ *
+ * Contributor(s):
+ * If you wish your version of this file to be governed by only the CDDL or
+ * only the GPL Version 2, indicate your decision by adding "[Contributor]
+ * elects to include this software in this distribution under the [CDDL or GPL
+ * Version 2] license."  If you don't indicate a single choice of license, a
+ * recipient has the option to distribute your version of this file under
+ * either the CDDL, the GPL Version 2 or to extend the choice of license to
+ * its licensees as provided above.  However, if you add GPL Version 2 code
+ * and therefore, elected the GPL Version 2 license, then the option applies
+ * only if the new code is made subject to such option by the copyright
+ * holder.
+ */
+package org.glassfish.hk2.maven;
+
+import java.util.Arrays;
+import java.util.Collections;
+import java.util.List;
+import java.util.regex.Matcher;
+import java.util.regex.Pattern;
+import org.apache.maven.shared.osgi.DefaultMaven2OsgiConverter;
+import org.apache.maven.shared.osgi.Maven2OsgiConverter;
+import org.codehaus.plexus.util.StringUtils;
+
+/**
+ *
+ * @author Romain Grecourt
+ */
+public class Version {
+
+    public enum COMPONENT {
+        major,
+        minor,
+        micro,
+        qualifier
+    };
+    
+    private static final int DIGITS_INDEX = 1;
+    public static final Pattern STANDARD_PATTERN = Pattern.compile(
+            "^((?:\\d+\\.)*\\d+)" // digit(s) and '.' repeated - followed by digit (version digits 1.22.0, etc)
+            + "([-_])?" // optional - or _  (annotation separator)
+            + "([a-zA-Z]*)" // alpha characters (looking for annotation - alpha, beta, RC, etc.)
+            + "([-_])?" // optional - or _  (annotation revision separator)
+            + "(\\d*)" // digits  (any digits after rc or beta is an annotation revision)
+            + "(?:([-_])?(.*?))?$");  // - or _ followed everything else (build specifier)
+    String orig;
+    int major = 0;
+    int minor = 0;
+    int incremental = 0;
+    String qualifier = "";
+
+    public Version(String v) {
+        orig = v;
+        List<String> digits = parseDigits(v);
+        major = getDigit(digits, 0);
+        minor = getDigit(digits, 1);
+        incremental = getDigit(digits, 2);
+        if(orig.contains("-")){
+            qualifier = orig.substring(orig.indexOf('-')+1);
+        }
+    }
+
+    private static int getDigit(List<String> digits, int idx) {
+        if (digits.size() >= idx + 1
+                && digits.get(idx) != null
+                && !digits.get(idx).isEmpty()) {
+            return Integer.parseInt(digits.get(idx));
+        }
+        return 0;
+    }
+
+    private List<String> parseDigits(String vStr) {
+        Matcher m = STANDARD_PATTERN.matcher(vStr);
+        if (m.matches()) {
+            return Arrays.asList(StringUtils.split(
+                    m.group(DIGITS_INDEX),
+                    "."));
+        }
+        return Collections.EMPTY_LIST;
+    }
+
+    public int getMajorVersion() {
+        return major;
+    }
+
+    public int getMinorVersion() {
+        return minor;
+    }
+
+    public int getIncrementalVersion() {
+        return incremental;
+    }
+    
+    public String getQualifier(){
+        return qualifier;
+    }
+
+    private static String formatString4Osgi(String s){
+        return s.replaceAll("-", "_").replaceAll("\\.", "_");
+    }
+    
+    public String convertToOsgi(COMPONENT comToDrop) {
+        Maven2OsgiConverter converter = new DefaultMaven2OsgiConverter();
+
+        if (comToDrop != null) {
+            switch (comToDrop) {
+                case major: {
+                    return converter.getVersion("0.0.0");
+                }
+                case minor: {
+                    return converter.getVersion(String.valueOf(getMajorVersion()));
+                }
+                case micro: {
+                    return converter.getVersion(String.format("%s.%s",
+                            getMajorVersion(),
+                            getMinorVersion()));
+                }
+                case qualifier: {
+                    return converter.getVersion(String.format("%s.%s.%s",
+                            getMajorVersion(),
+                            getMinorVersion(),
+                            getIncrementalVersion()));
+                }
+            }
+        }
+        
+        // init version major.minor.micro
+        String version = String.format("%s.%s.%s",
+                getMajorVersion(),
+                getMinorVersion(),
+                getIncrementalVersion());
+        
+        // if there is a qualifier, add it
+        if(!getQualifier().isEmpty()){
+            version = String.format("%s.%s",
+                    version,
+                    formatString4Osgi(getQualifier()));
+        }
+        return converter.getVersion(version);
+    }
+}
diff --git a/hk2/osgiversion-maven-plugin/src/test/java/org/glassfish/hk2/maven/VersionTest.java b/hk2/osgiversion-maven-plugin/src/test/java/org/glassfish/hk2/maven/VersionTest.java
new file mode 100644
index 0000000..8802fbe
--- /dev/null
+++ b/hk2/osgiversion-maven-plugin/src/test/java/org/glassfish/hk2/maven/VersionTest.java
@@ -0,0 +1,71 @@
+/*
+ * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS HEADER.
+ *
+ * Copyright (c) 2013 Oracle and/or its affiliates. All rights reserved.
+ *
+ * The contents of this file are subject to the terms of either the GNU
+ * General Public License Version 2 only ("GPL") or the Common Development
+ * and Distribution License("CDDL") (collectively, the "License").  You
+ * may not use this file except in compliance with the License.  You can
+ * obtain a copy of the License at
+ * https://glassfish.dev.java.net/public/CDDL+GPL_1_1.html
+ * or packager/legal/LICENSE.txt.  See the License for the specific
+ * language governing permissions and limitations under the License.
+ *
+ * When distributing the software, include this License Header Notice in each
+ * file and include the License file at packager/legal/LICENSE.txt.
+ *
+ * GPL Classpath Exception:
+ * Oracle designates this particular file as subject to the "Classpath"
+ * exception as provided by Oracle in the GPL Version 2 section of the License
+ * file that accompanied this code.
+ *
+ * Modifications:
+ * If applicable, add the following below the License Header, with the fields
+ * enclosed by brackets [] replaced by your own identifying information:
+ * "Portions Copyright [year] [name of copyright owner]"
+ *
+ * Contributor(s):
+ * If you wish your version of this file to be governed by only the CDDL or
+ * only the GPL Version 2, indicate your decision by adding "[Contributor]
+ * elects to include this software in this distribution under the [CDDL or GPL
+ * Version 2] license."  If you don't indicate a single choice of license, a
+ * recipient has the option to distribute your version of this file under
+ * either the CDDL, the GPL Version 2 or to extend the choice of license to
+ * its licensees as provided above.  However, if you add GPL Version 2 code
+ * and therefore, elected the GPL Version 2 license, then the option applies
+ * only if the new code is made subject to such option by the copyright
+ * holder.
+ */
+package org.glassfish.hk2.maven;
+
+import junit.framework.Assert;
+import org.junit.Test;
+
+/**
+ *
+ * @author Romain Grecourt
+ */
+public class VersionTest {
+    
+    public static void doTest(
+            String orig,
+            Version.COMPONENT compToDrop,
+            String expected) {
+
+        String actual = new Version(orig).convertToOsgi(compToDrop);
+        Assert.assertEquals(
+                String.format("orig=%s ; compToDrop=%s ; expected=%s ; actual=%s", orig, String.valueOf(compToDrop), expected, actual),
+                expected,
+                actual);
+    }
+    
+    @Test
+    public void simpleTests(){
+        doTest("4.0.1-SNAPSHOT",Version.COMPONENT.qualifier,"4.0.1");
+        doTest("12.1.3.339",Version.COMPONENT.qualifier,"12.1.3");
+        doTest("12.1.3.339",null,"12.1.3");
+        doTest("12.1.3.0.0-130717.3355",null,"12.1.3.130717_3355");
+        doTest("12.1.3.0.0-130717.3355",Version.COMPONENT.qualifier,"12.1.3");
+    }
+}




[GRIZZLY-1497] Support for filters in the OSGi HTTP Service Created: 13/Apr/13  Updated: 07/Jun/13  Resolved: 07/Jun/13

Status: Resolved
Project: grizzly
Component/s: None
Affects Version/s: 2.3
Fix Version/s: 2.3.3, 3.0

Type: New Feature Priority: Major
Reporter: pbakker Assignee: Ryan Lubke
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: osgi

 Description   

Although the Http Service specification doesn't support filters (yet), they are still often required. Apache Felix HTTP offers an extension to the standard HTTP Service (ExtHTTP) that can be used to register filters. Something similar could be done in Grizzly.



 Comments   
Comment by Ryan Lubke [ 09/May/13 ]

Looking into this either late this week or early next.

Comment by Ryan Lubke [ 15/May/13 ]

After a review of the code, there will need to be some re-work. Right now, there is Filter support buried within the internals, however, the Filters are associated on a per-Servlet case. Looking at the ExtHttpService example referenced, it allows Filters to be associated with namespaces like standard Servlets. Will have to adjust the clean mapper to account for this addition.

In addition to Filters - perhaps it would be a good idea to add Listener support as well.

Comment by Ryan Lubke [ 16/May/13 ]

Initial implementation is complete. Needs some cleanup and tests.

Comment by Ryan Lubke [ 17/May/13 ]

Initial changes applied.

2.3.x: d663f8a372e64dad7c8b17ead350a95a21c5c443
master: 7237b9e8a496c8b5d7c37d48df6b1e133f98e1ad

Comment by Ryan Lubke [ 17/May/13 ]

I've pushed a 2.3.2-SNAPSHOT build that includes the above changes. I'd appreciate if you could kick the tires a bit.

Some info on the changes.

Added HttpServiceExtension:

/**
 * An extension to the OSGi {@link HttpService} interface allowing the
 * registration/unregistration of Servlet {@link Filter} instances.
 *
 * @since 2.3.3
 */
public interface HttpServiceExtension extends HttpService {


    /**
     * Registers a {@link Filter} and with the {@link HttpService}.
     *
     * As this is an extension to the standard {@link HttpService} and there
     * are no clear rules on how the mapping of filters should occur,
     * this implementation follows the mapping rules as defined by the Servlet
     * specification.
     *
     * Additionally, it should be noted that the registered {@link Filter}s are
     * effectively associated with a particular {@link HttpContext}.  Therefore,
     * if you wish to have multiple filters associated with a particular
     * {@link javax.servlet.Servlet}, then you should use the same {@link HttpContext}
     * instance to perform the registration.
     *
     * {@link Filter}s will be invoked in registration order.
     *
     * This method will invoke {@link Filter#init(javax.servlet.FilterConfig)} during
     * the registration process.
     *
     * When registering a {@link Filter}, take care not to reuse the same Filter
     * instance across multiple registration invocations.  This could cause issues
     * when removing the Filter as it may remove more url matching possibilities
     * than intended.
     *
     * @param filter the {@link Filter} to register.
     * @param urlPattern the url pattern that will invoke this {@link Filter}.
     * @param initParams the initialization params that will be passed to the
     *                   filter when {@link Filter#init(javax.servlet.FilterConfig)}
     *                   is invoked.
     * @param context the {@link HttpContext} associated with this {@link Filter}.
     *
     * @throws ServletException if an error occurs during {@link Filter} initialization.
     */
    public void registerFilter(final Filter filter,
                                          final String urlPattern,
                                          final Dictionary initParams,
                                          final HttpContext context) throws ServletException;

    /**
     * Removes the specified {@link Filter} from the service.
     *
     * @param filter the {@link Filter} to remove.
     */
    public void unregisterFilter(final Filter filter);

}

Will keep the issue open for the time being awaiting feedback.

Comment by pbakker [ 21/May/13 ]

Great! I will try this out soon.

FYI: there is also some spec work being done in this area within the OSGi Enterprise Expert Group. A public draft is available: http://www.osgi.org/Download/File?url=/download/osgi-early-draft-2013-03.pdf

Comment by Ryan Lubke [ 23/May/13 ]

Thanks for the link. I glossed over it briefly and it looks like they've tightened quite a few things down, which is good. I'll review more closely as soon as time permits and make adjustments to the implementation as needed.

Comment by Ryan Lubke [ 29/May/13 ]

Just checking back to see if you've had cycles to test the changes. We'd like to release 2.3.3 fairly soon, but would like to make sure this works for you first.

Comment by Ryan Lubke [ 07/Jun/13 ]

Closing this out for now. If, upon testing, you find an issue, please feel free to reopen.





[GRIZZLY-1496] Make gmbal an optional import Created: 13/Apr/13  Updated: 11/May/13  Resolved: 11/May/13

Status: Resolved
Project: grizzly
Component/s: None
Affects Version/s: 2.3
Fix Version/s: 2.3.3, 3.0

Type: Improvement Priority: Minor
Reporter: pbakker Assignee: oleksiys
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: osgi

 Description   

The Grizzly bundles are currently not self contained, they have an import on gmbal. This is only an API dependency however. An optional import would be preferable, so that Grizzly can optionally be used as a self contained bundle.



 Comments   
Comment by Ryan Lubke [ 09/May/13 ]

This appears related to https://java.net/jira/browse/GRIZZLY-1477.

Comment by oleksiys [ 11/May/13 ]

resolved.

Gmbal is separated out.





[GRIZZLY-1495] Use Configuration Admin for configuration in OSGi environments Created: 13/Apr/13  Updated: 12/Aug/13

Status: Open
Project: grizzly
Component/s: None
Affects Version/s: 2.3
Fix Version/s: 2.x.NEXT

Type: Improvement Priority: Major
Reporter: pbakker Assignee: Ryan Lubke
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: osgi

 Description   

Configuration properties such as the port to listen on are now configured within the bundle itself, which is not flexible.
The standard way of providing configuration in OSGi is using Configuration Admin (part of the compendium spec). Grizzly should be configured this way as well.



 Comments   
Comment by Ryan Lubke [ 09/May/13 ]

Will look into this next week.





[GRIZZLY-1049] Add support for OSGi HttpService in Grizzly 2.x Created: 01/Aug/11  Updated: 23/Aug/11  Resolved: 23/Aug/11

Status: Resolved
Project: grizzly
Component/s: None
Affects Version/s: 2.1.1
Fix Version/s: 2.1.2

Type: New Feature Priority: Major
Reporter: David GAY Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Java 6


Tags: Grizzly, HttpService, OSGi

 Description   

Grizzly 1.9.x provide an implementation for the standard OSGi HttpService.

Please provides the same implementation based on Grizzly 2.0



 Comments   
Comment by oleksiys [ 01/Aug/11 ]

initial code migration.
needs to be checked.

Project: grizzly
Repository: git
Revision: 73e0db6c6f2ad7bd92e9b944f906d78b85504fbf
Author: oleksiys
Date: 2011-08-01 18:29:15 UTC
Link:

Log Message:
------------
http://java.net/jira/browse/GRIZZLY-1049
"Add support for OSGi HttpService in Grizzly 2.x"

Comment by David GAY [ 22/Aug/11 ]

Hi,

I finally find some time to check it.
It works ok on my env in a Felix OSGi runtime

Thanks.
David.

Comment by oleksiys [ 23/Aug/11 ]

ported





[GLASSFISH-21050] Problem with classloader and casting using osgi gf-client-module to access remote EJB (RMI) from GF4. Created: 23/Apr/14  Updated: 23/Apr/14

Status: Open
Project: glassfish
Component/s: OSGi
Affects Version/s: 4.0
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: PashaTurok Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Server:centos 6.4, 64, openjdk 7
Client:centos 6.4, 64, openjdk 7


Tags: ejb31, glassfish4, javaee, osgi, osgi-javaee

 Description   

I have server-client architecture. Server and client different machines in one local network. Both server and client are on osgi framework. For server it's hybrid EJB. There are three osgi bundles:for server,for client and shared. The copy of shared is both on server and on clients and contains LanguageDirBeanRemote and LanguageDirEntity. To get my bean I use the following code on osgi-client:

ClassLoader thatLoader = Thread.currentThread().getContextClassLoader();
Thread.currentThread().setContextClassLoader(getClass().getClassLoader());
try {
Properties jndiProps = new Properties();
jndiProps.put("java.naming.factory.initial", "com.sun.enterprise.naming.impl.SerialInitContextFactory");
jndiProps.put("java.naming.factory.url.pkgs", "com.sun.enterprise.naming");
jndiProps.put("java.naming.factory.state", "com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl");
jndiProps.setProperty("org.omg.CORBA.ORBInitialHost", "x.x.x.x");
jndiProps.setProperty("org.omg.CORBA.ORBInitialPort", "3700");
InitialContext ctx = new InitialContext(jndiProps);
LanguageDirBeanRemote bean=(LanguageDirBeanRemote)ctx.lookup("java:global/...");
ArrayList<LanguageDirEntity> elements=bean.readDirectory();
System.out.println("HERE I GET THE ERROR:"+elements.get(0).getContent());
} finally {
Thread.currentThread().setContextClassLoader(thatLoader);
}

Here is the log:
java.lang.ClassCastException: com.test.cmn.shd.base.dir.language.LanguageDirEntity cannot be cast to com.test.cmn.shd.base.dir.language.LanguageDirEntity at com.test.cmn.dt.base.Activator.start(Activator.java:83) at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:645) at org.apache.felix.framework.Felix.activateBundle(Felix.java:1977) at org.apache.felix.framework.Felix.startBundle(Felix.java:1895) at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944) at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:931) at com.test.cmn.dt.loader.LoaderModel.startCoreModule(LoaderModel.java:149) at com.test.cmn.dt.loader.LoaderModel.access$100(LoaderModel.java:39) at com.test.cmn.dt.loader.LoaderModel$InstallAndStartModuleWorker.doInBackground(LoaderModel.java:79) at com.test.cmn.dt.loader.LoaderModel$InstallAndStartModuleWorker.doInBackground(LoaderModel.java:73) at javax.swing.SwingWorker$1.call(SwingWorker.java:296) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at javax.swing.SwingWorker.run(SwingWorker.java:335) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:744)

The reason that I think it's the bug is that the following code works without any problems:
LanguageDirEntity[] elements=bean.readDirectoryAsArray();
We see, that using simple array, without ArrayList we get no errors. But when I try to use ArrayList or ArrayList<LanguageDirEntity> I get ClassCastException. I think the problem is somewhere in RMI when it loads classes.
This prblem I also described on stackoverflow. http://stackoverflow.com/questions/23174582/arraylist-classloader-issue-in-osgi-client-javaeeejb-server






[GLASSFISH-20977] gf-client-module.jar is an OSGi bundle, but should not be Created: 10/Feb/14  Updated: 19/Sep/14  Resolved: 20/Aug/14

Status: Resolved
Project: glassfish
Component/s: build_system
Affects Version/s: 4.0
Fix Version/s: 4.1

Type: Bug Priority: Major
Reporter: Romain Grécourt Assignee: Romain Grécourt
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 4_0_1-approved, 4_0_1-reviewed, build, osgi

 Description   

Caused by: org.osgi.framework.BundleException: Unresolved constraint in bundle org.glassfish.main.appclient.gf-client-module [67]: Unable to resolve 67.0: missing requirement [67.0] osgi.wiring.package; (osgi.wiring.package=org.jboss.weld.environment.se)
at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3974)
at org.apache.felix.framework.Felix.startBundle(Felix.java:2037)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:955)
at org.jvnet.hk2.osgiadapter.OSGiModuleImpl.start(OSGiModuleImpl.java:210)



 Comments   
Comment by Romain Grécourt [ 19/Aug/14 ]

removing the OSGi metadata, makes the bundle starts.

However, it's still installed and shows up as:

   83|Active     |    1|file:/Users/romano/workspaces/glassfish/main2/appserver/distributions/glassfish/target/stage/glassfish4/glassfish/modules/gf-client-module.jar (0.0.0)
Comment by Romain Grécourt [ 20/Aug/14 ]

We will instead make the org.jboss.weld.environment.se import optional to allow this bundle to be started.

Comment by Romain Grécourt [ 20/Aug/14 ]
Log Message:
------------
fix for GLASSFISH-20977


Revisions:
----------
63645


Modified Paths:
---------------
trunk/main/appserver/appclient/client/acc/osgi.bundle


Diffs:
------
Index: trunk/main/appserver/appclient/client/acc/osgi.bundle
===================================================================
--- trunk/main/appserver/appclient/client/acc/osgi.bundle	(revision 63644)
+++ trunk/main/appserver/appclient/client/acc/osgi.bundle	(revision 63645)
@@ -43,3 +43,12 @@
                         org.glassfish.appclient.client.acc; \
                         org.glassfish.appclient.client.acc.callbackhandler;
                         org.glassfish.appclient.common; version=${project.osgi.version}
+
+# GLASSFISH-20977
+# This bundle is an OSGi bundle for convenience.
+# However it needs org.jboss.weld.environment.se package, which isn't provided in GlassFish.
+# The result is a non start-able OSGi bundle.
+# Making this import optional.
+Import-Package: \
+                        org.jboss.weld.environment.se;resolution:=optional, \
+                        *




[GLASSFISH-20838] Move 3rd party repackaged OSGi bundles out of the GlassFish workspace / build Created: 01/Oct/13  Updated: 15/Oct/13

Status: Open
Project: glassfish
Component/s: build_system
Affects Version/s: 4.0
Fix Version/s: future release

Type: Improvement Priority: Major
Reporter: Romain Grécourt Assignee: Romain Grécourt
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 2 days
Time Spent: Not Specified
Original Estimate: 2 days

Tags: 3rdparty, maven, osgi, packaging

 Description   

The non OSGied 3rd party artifacts are repackaged in the packager/external modules (main/nucleus/packager/external and main/appserver/packager/external).

Those 3party artifacts don't change often, but are part of the GlassFish build and hence published as part of every published build of GlassFish.
Also, there is no easy way to figure out what version of the 3rd party is used as the GlassFish version is used.

Instead, we should release those modules separately.

This would allow us to binary integrate those repackaged osgi bundles in the build, removing a bunch of modules from the build and the confusion around the version.
I'd suggest we put them in https://svn.java.net/svn/glassfish~svn/trunk/external/modules/, and provide a release.sh script for each module (see https://svn.java.net/svn/glassfish~svn/trunk/api/javaee-api/javax.annotation/release.sh) to facilitate the release process.

Also, we could provide a standard wiki page that describes how to setup the "maven release" environment.

Here is a list of the involved modules:

  • antlr
  • j-interop
  • jmxremote_optional
  • ldapbp
  • trilead-ssh2
  • vboxjws
  • ant
  • dbschema
  • javadb
  • jaxr_ra
  • jmsra
  • libpam4j
  • schema2beans

Some of the repackaged artifacts are not issued from Maven workspace, hence their dependency graph maybe incorrect (or inexistant).
We can leverage that to remove some workarounds present in the GlassFish workspace:

  • findbugs needs org.netbeans.external:ddl when introspecting code that uses either dbschema or schema2beans
  • antlr maven plugin expect the original antlr dependency in the graph, however it's not provided by our repackaged artifact, hence we have to add the original antlr dependency just to satisfy the plugin. (see ./appserver/persistence/cmp/support-sqlstore/pom.xml)





[GLASSFISH-19390] Deploying WAB results in EclipseLink enhanced bytes regardless of JPA provider Created: 27/Nov/12  Updated: 29/Nov/12  Resolved: 28/Nov/12

Status: Closed
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: 3.1.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: chejavara Assignee: Sanjeeb Sahoo
Resolution: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by GLASSFISH-19365 Deploying WAB results in EclipseLink ... Closed
Tags: eclipselink, osgi

 Description   

I have a web application bundle with a persistence unit defined in persistence.xml

The provider is set to hibernate
<provider>org.hibernate.ejb.HibernatePersistence</provider>

No matter what when the WAB is deploying in OSGI environment, EclipseLink Enhancer will enhance all of my entity classes. This is due to the following stack trace:

EclipseLinkEnhancer.enhance(Bundle, List<Persistence>) line: 81
JPABundleProcessor.enhance() line: 144
JPAExtender.enhance(JPABundleProcessor, boolean) line: 174
JPAExtender.access$100(JPAExtender, JPABundleProcessor, boolean) line: 64
JPAExtender$1.run() line: 130
JPAExtender.executeTask(Runnable, JPAExtender$EnhancerPolicy) line: 203
JPAExtender.bundleChanged(BundleEvent) line: 139
EventDispatcher.invokeBundleListenerCallback(Bundle, EventListener, EventObject) line: 807
EventDispatcher.fireEventImmediately(EventDispatcher, int, Object[], EventObject, Dictionary) line: 729
EventDispatcher.fireBundleEvent(BundleEvent) line: 610
Felix.fireBundleEvent(int, Bundle) line: 3758
Felix.installBundle(long, String, BundleArchive, InputStream) line: 2640
Felix.installBundle(String, InputStream) line: 2436
BundleContextImpl.installBundle(String, InputStream) line: 129
BundleContextImpl.installBundle(String) line: 107

and the JPABundleProcessor decides to do this in enhance():

JPAEnhancer enhancer = new EclipseLinkEnhancer();
InputStream enhancedStream = enhancer.enhance(getBundle(), persistenceXMLs);

The EclipseLink enhancing should not take place if we are not using EclipseLink as the provider, right?

I have tried setting:
org.glassfish.osgjpa.extension.useHybridPersistenceProviderResolver=true in config.properties

and tried setting
<property name="eclipselink.weaving" value="false"/> in persistence.xml to no avail.

The only way I see is to include GlassFish-StaticallyWeaved manifest header in manifest.mf.

Seems to me that EclipseLink enhancing by default should be OFF and possibly turn it ON with the manifest header and not the other way around, because not everyone will be using EclipseLink enhancing?



 Comments   
Comment by Sanjeeb Sahoo [ 28/Nov/12 ]

The fact of the matter is we currently don't support any other JPA provider in OSGi mode, so we assume it's eclipselink and enhance the bytes when we see a JPA bundle. There are other RFEs filed in JIRA to add support for other JPA providers. When we support them, we will pay attention to the kind of provider being used by an app.

Comment by chejavara [ 28/Nov/12 ]

Thats suprising

What doesn't work with those providers, what would you need to to do to support them? So far I don't see anything because I tested both OpenJPA and Hibernate and they worked in my test cases.

Do you have links to the JIRA issues, so I know what doesn't work?

Comment by Sanjeeb Sahoo [ 28/Nov/12 ]

See GLASSFISH-19284 and GLASSFISH-12275.

Comment by chejavara [ 28/Nov/12 ]

Thanks for the info, I think I may see why, I wasn't using it with EJB.

Comment by TangYong [ 29/Nov/12 ]

Currently, JPA Enhancer happened on a jpa bundle's installed/updated/started unless you specify "GlassFish-StaticallyWeaved = true" in MANIFEST.MF file, and once starting executing enhance, osgi-jpa uses EclipseLinkEnhancer, still not supporting Hibernate and OpenJPA's enhance strategies, so, a workaround is setting "GlassFish-StaticallyWeaved = true" in MANIFEST.MF file.

As to how to support other persistence vendors's enhance strategies, firstly, we need to do the following,

1) investigate how Hibernate and OpenJPA use enhance strategy

2) modify JPABundleProcessor.enhance() to judge JPA provider from persistent.xml and call persistence vendors's enhance strategies

just as sahoo's saying, please pay attention to GLASSFISH-12275(Hibernate's enhance) and GLASSFISH-19284(OpenJPA's enhance).

Please seeing whether the workaround is available(not using enhance)

Thanks.
--Tang





[GLASSFISH-19022] undeploying an osgi bundle having HK2 services result in stale service entries in the runtime Created: 20/Aug/12  Updated: 02/Oct/12  Resolved: 02/Oct/12

Status: Resolved
Project: glassfish
Component/s: hk2
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Jagadish Assignee: mtaube
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: hk2, osgi

 Description   

We use "deploy --type osgi <osgi-enabled-hk2-bundle>.jar" which helps to install an osgi bundle as application in GlassFish
This also exposes the hk2 services in the bundle.
When uninstalling the bundle (or via "undeploy appName") that has hk2 services, these services are still listed in the runtime.
eg: habitat.getAllByContract(..) will also list the HK2 Service implementation that was actually removed as part of uninstalling the bundle.
Accessing such an entry results in class-not-found-exceptions.

This seems to be a bug. Once GlassFish is restarted, the stale entries are removed as expected.



 Comments   
Comment by mtaube [ 02/Oct/12 ]

This should be fixed at revision 56196, I've verified it on the hk2 side with a pax-based integration test.





[GLASSFISH-18973] Integrate the OSGi Remote Services implementation(eg. Apache CXF Distributed OSGi) Created: 03/Aug/12  Updated: 29/Nov/12

Status: Open
Project: glassfish
Component/s: OSGi
Affects Version/s: future release
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: TangYong Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 0
Labels: None
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Sub-Tasks:
Key
Summary
Type
Status
Assignee
GLASSFISH-19401 Adding org.apache.cxf.dosgi.discovery... Sub-task Open Sanjeeb Sahoo  
Tags: Distributed, OSGi

 Description   

[BackGround]
[Reference By https://issues.jboss.org/browse/JBOSGI-322]
The Enterprise OSGi Spec describes OSGi Remote Services which is a way to Distribute OSGi Services.
An implementation on top of Web Services and REST is available at the CXF Distributed OSGi project (http://cxf.apache.org/distributed-osgi.html).

Integrating this in the JBoss OSGi distribution would provide it with support for this important OSGi spec.

[Requirement]
In a distributed soa/cloud enviroment, in order to decouple the whole system and use the subsystems dynamicly, user can use osgi. However, because subsystems/modules can be distributed across the whole system, as a framework of publishing/consuming services, glassfish should have an capability to support Distributed OSGi.

[Integration Example]
"Deploying CXF-DOSGi to JBoss AS7"
https://community.jboss.org/thread/174136



 Comments   
Comment by TangYong [ 03/Aug/12 ]

Once implementing the feature, It will offer a hybrid JavaEE App more options.

Comment by TangYong [ 23/Aug/12 ]

Now, the integration work will start and use Multi Bundle Distribution of CXF Distributed OSGi.

DCXF Version: 1.3.1

Comment by TangYong [ 23/Aug/12 ]

Step 1(Glassfish Felix Runtime Integration)

Step1.1 Analysing DCXF Dependent Bundles
[Background]
Because some of DCXF dependent bundles belong to other open souce implementation of specfications, we must analyse these bundles to confirm whether glassfish has the corresponding implementations or not and if having, we will replace them using glassfish implementations. DCXF Dependent Bundles needed to be analysed are following(removing dcxf-related bundles and org.osgi.compendium-4.2.0.jar and org.osgi.enterprise-4.2.0.jar):
-------------------------------------------------------------------------
geronimo-annotation_1.0_spec-1.1.1.jar
dosgi_bundles/geronimo-activation_1.1_spec-1.1.jar
geronimo-javamail_1.4_spec-1.2.jar
geronimo-servlet_3.0_spec-1.0.jar
geronimo-ws-metadata_2.0_spec-1.1.3.jar
com.springsource.org.apache.commons.logging-1.1.1.jar
com.springsource.org.jdom-1.1.0.jar
spring-core-3.0.6.RELEASE.jar
spring-beans-3.0.6.RELEASE.jar
spring-context-3.0.6.RELEASE.jar
com.springsource.org.aopalliance-1.0.0.jar
com.springsource.slf4j.api-1.5.10.jar
com.springsource.slf4j.jcl-1.5.10.jar
spring-aop-3.0.6.RELEASE.jar
spring-asm-3.0.6.RELEASE.jar
spring-expression-3.0.6.RELEASE.jar
spring-osgi-io-1.2.1.jar
spring-osgi-core-1.2.1.jar
spring-osgi-extender-1.2.1.jar
jetty-all-server-7.4.2.v20110526.jar
pax-web-spi-1.0.3.jar
pax-web-runtime-1.0.3.jar
pax-web-jetty-1.0.3.jar
org.apache.servicemix.bundles.jaxb-impl-2.1.13_2.jar
org.apache.servicemix.bundles.wsdl4j-1.6.2_5.jar
org.apache.servicemix.bundles.xmlsec-1.4.5_1.jar
xmlschema-core-2.0.1.jar
org.apache.servicemix.bundles.asm-3.3_2.jar
org.apache.servicemix.bundles.xmlresolver-1.2_4.jar
neethi-3.0.1.jar
stax2-api-3.1.1.jar
woodstox-core-asl-4.1.1.jar
org.apache.servicemix.bundles.commons-pool-1.5.4_1.jar
org.apache.servicemix.specs.saaj-api-1.3-1.9.0.jar
org.apache.servicemix.specs.stax-api-1.0-1.9.0.jar
org.apache.servicemix.specs.jaxb-api-2.1-1.9.0.jar
org.apache.servicemix.specs.jaxws-api-2.1-1.9.0.jar
org.apache.servicemix.specs.jsr311-api-1.1.1-1.9.0.jar
org.apache.servicemix.bundles.joda-time-1.5.2_4.jar
org.apache.servicemix.bundles.opensaml-2.4.1_1.jar
--------------------------------------------------------------------------

Comment by TangYong [ 25/Aug/12 ]

> Step1.1 Analysing DCXF Dependent Bundles

About initial analysing result, please see [1],

[1] https://github.com/tangyong/Integrating-Glassfish-With-OSGi-Remote-Services-implementation/issues/1

To summary, I will place the following depenedent bundles and dcxf bundles into glassfish autostart/,

(1) com.springsource.org.apache.commons.logging-1.1.1.jar
(2) com.springsource.org.jdom-1.1.0.jar
(3) spring-core-3.0.6.RELEASE.jar
(4) spring-beans-3.0.6.RELEASE.jar
(5) spring-context-3.0.6.RELEASE.jar
(6) com.springsource.org.aopalliance-1.0.0.jar
(7) com.springsource.slf4j.api-1.5.10.jar
(8) com.springsource.slf4j.jcl-1.5.10.jar
(9) spring-aop-3.0.6.RELEASE.jar
(10) spring-asm-3.0.6.RELEASE.jar
(11) spring-expression-3.0.6.RELEASE.jar
(12) spring-osgi-io-1.2.1.jar
(13) spring-osgi-core-1.2.1.jar
(14) spring-osgi-extender-1.2.1.jar
(15) org.apache.servicemix.bundles.wsdl4j-1.6.2_5.jar (Note: I am waiting the reply from dev team)
(16) xmlschema-core-2.0.1.jar
(17) org.apache.servicemix.bundles.asm-3.3_2.jar
(18) org.apache.servicemix.bundles.xmlresolver-1.2_4.jar
(19) neethi-3.0.1.jar
(20) org.apache.servicemix.bundles.commons-pool-1.5.4_1.jar
(21) org.apache.servicemix.bundles.joda-time-1.5.2_4.jar
(22) org.apache.servicemix.bundles.opensaml-2.4.1_1.jar
(23) cxf-bundle-minimal-2.5.2.jar
(24) cxf-dosgi-ri-discovery-local-1.3.1.jar
(25) org.osgi.enterprise-4.2.0.jar
(26) cxf-dosgi-ri-dsw-cxf-1.3.1.jar
(27) cxf-dosgi-ri-topology-manager-1.3.1.jar

Comment by TangYong [ 25/Aug/12 ]

Step1.2: based Step1.1 result, place the dcxf and dependent bundles into osgi.properties and apply these bundle's start levels

On original dcxf's conf\felix.config.properties.append file, start level descriptions are as following,

org.ops4j.pax.web.session.timeout=30
org.osgi.framework.startlevel.beginning=95
felix.auto.start.50=http://repo2.maven.org/maven2/org/osgi/org.osgi.compendium/4.2.0/org.osgi.compendium-4.2.0.jar

felix.auto.start.51=file:apache-cxf-dosgi-ri-1.3.1/dosgi_bundles/geronimo-annotation_1.0_spec-1.1.1.jar
felix.auto.start.52=file:apache-cxf-dosgi-ri-1.3.1/dosgi_bundles/geronimo-activation_1.1_spec-1.1.jar
felix.auto.start.53=file:apache-cxf-dosgi-ri-1.3.1/dosgi_bundles/geronimo-javamail_1.4_spec-1.2.jar
felix.auto.start.54=file:apache-cxf-dosgi-ri-1.3.1/dosgi_bundles/geronimo-servlet_3.0_spec-1.0.jar
felix.auto.start.55=file:apache-cxf-dosgi-ri-1.3.1/dosgi_bundles/geronimo-ws-metadata_2.0_spec-1.1.3.jar
felix.auto.start.56=file:apache-cxf-dosgi-ri-1.3.1/dosgi_bundles/com.springsource.org.apache.commons.logging-1.1.1.jar
felix.auto.start.57=file:apache-cxf-dosgi-ri-1.3.1/dosgi_bundles/com.springsource.org.jdom-1.1.0.jar
felix.auto.start.58=file:apache-cxf-dosgi-ri-1.3.1/dosgi_bundles/spring-core-3.0.6.RELEASE.jar
felix.auto.start.59=file:apache-cxf-dosgi-ri-1.3.1/dosgi_bundles/spring-beans-3.0.6.RELEASE.jar
felix.auto.start.60=file:apache-cxf-dosgi-ri-1.3.1/dosgi_bundles/spring-context-3.0.6.RELEASE.jar
felix.auto.start.61=file:apache-cxf-dosgi-ri-1.3.1/dosgi_bundles/com.springsource.org.aopalliance-1.0.0.jar
felix.auto.start.62=file:apache-cxf-dosgi-ri-1.3.1/dosgi_bundles/com.springsource.slf4j.api-1.5.10.jar
felix.auto.start.63=file:apache-cxf-dosgi-ri-1.3.1/dosgi_bundles/com.springsource.slf4j.jcl-1.5.10.jar
felix.auto.start.64=file:apache-cxf-dosgi-ri-1.3.1/dosgi_bundles/spring-aop-3.0.6.RELEASE.jar
felix.auto.start.65=file:apache-cxf-dosgi-ri-1.3.1/dosgi_bundles/spring-asm-3.0.6.RELEASE.jar
felix.auto.start.66=file:apache-cxf-dosgi-ri-1.3.1/dosgi_bundles/spring-expression-3.0.6.RELEASE.jar
felix.auto.start.67=file:apache-cxf-dosgi-ri-1.3.1/dosgi_bundles/spring-osgi-io-1.2.1.jar
felix.auto.start.68=file:apache-cxf-dosgi-ri-1.3.1/dosgi_bundles/spring-osgi-core-1.2.1.jar
felix.auto.start.69=file:apache-cxf-dosgi-ri-1.3.1/dosgi_bundles/spring-osgi-extender-1.2.1.jar
felix.auto.start.70=file:apache-cxf-dosgi-ri-1.3.1/dosgi_bundles/jetty-all-server-7.4.2.v20110526.jar
felix.auto.start.71=file:apache-cxf-dosgi-ri-1.3.1/dosgi_bundles/pax-web-spi-1.0.3.jar
felix.auto.start.72=file:apache-cxf-dosgi-ri-1.3.1/dosgi_bundles/pax-web-runtime-1.0.3.jar
felix.auto.start.73=file:apache-cxf-dosgi-ri-1.3.1/dosgi_bundles/pax-web-jetty-1.0.3.jar
felix.auto.start.74=file:apache-cxf-dosgi-ri-1.3.1/dosgi_bundles/org.apache.servicemix.bundles.jaxb-impl-2.1.13_2.jar
felix.auto.start.75=file:apache-cxf-dosgi-ri-1.3.1/dosgi_bundles/org.apache.servicemix.bundles.wsdl4j-1.6.2_5.jar
felix.auto.start.76=file:apache-cxf-dosgi-ri-1.3.1/dosgi_bundles/org.apache.servicemix.bundles.xmlsec-1.4.5_1.jar
felix.auto.start.77=file:apache-cxf-dosgi-ri-1.3.1/dosgi_bundles/xmlschema-core-2.0.1.jar
felix.auto.start.78=file:apache-cxf-dosgi-ri-1.3.1/dosgi_bundles/org.apache.servicemix.bundles.asm-3.3_2.jar
felix.auto.start.79=file:apache-cxf-dosgi-ri-1.3.1/dosgi_bundles/org.apache.servicemix.bundles.xmlresolver-1.2_4.jar
felix.auto.start.80=file:apache-cxf-dosgi-ri-1.3.1/dosgi_bundles/neethi-3.0.1.jar
felix.auto.start.81=file:apache-cxf-dosgi-ri-1.3.1/dosgi_bundles/stax2-api-3.1.1.jar
felix.auto.start.82=file:apache-cxf-dosgi-ri-1.3.1/dosgi_bundles/woodstox-core-asl-4.1.1.jar
felix.auto.start.83=file:apache-cxf-dosgi-ri-1.3.1/dosgi_bundles/org.apache.servicemix.bundles.commons-pool-1.5.4_1.jar
felix.auto.start.84=file:apache-cxf-dosgi-ri-1.3.1/dosgi_bundles/org.apache.servicemix.specs.saaj-api-1.3-1.9.0.jar
felix.auto.start.85=file:apache-cxf-dosgi-ri-1.3.1/dosgi_bundles/org.apache.servicemix.specs.stax-api-1.0-1.9.0.jar
felix.auto.start.86=file:apache-cxf-dosgi-ri-1.3.1/dosgi_bundles/org.apache.servicemix.specs.jaxb-api-2.1-1.9.0.jar
felix.auto.start.87=file:apache-cxf-dosgi-ri-1.3.1/dosgi_bundles/org.apache.servicemix.specs.jaxws-api-2.1-1.9.0.jar
felix.auto.start.88=file:apache-cxf-dosgi-ri-1.3.1/dosgi_bundles/org.apache.servicemix.specs.jsr311-api-1.1.1-1.9.0.jar
felix.auto.start.89=file:apache-cxf-dosgi-ri-1.3.1/dosgi_bundles/org.apache.servicemix.bundles.joda-time-1.5.2_4.jar
felix.auto.start.90=file:apache-cxf-dosgi-ri-1.3.1/dosgi_bundles/org.apache.servicemix.bundles.opensaml-2.4.1_1.jar
felix.auto.start.91=file:apache-cxf-dosgi-ri-1.3.1/dosgi_bundles/cxf-bundle-minimal-2.5.2.jar
felix.auto.start.92=file:apache-cxf-dosgi-ri-1.3.1/dosgi_bundles/cxf-dosgi-ri-discovery-local-1.3.1.jar
felix.auto.start.93=file:apache-cxf-dosgi-ri-1.3.1/dosgi_bundles/org.osgi.enterprise-4.2.0.jar
felix.auto.start.94=file:apache-cxf-dosgi-ri-1.3.1/dosgi_bundles/cxf-dosgi-ri-dsw-cxf-1.3.1.jar
felix.auto.start.95=file:apache-cxf-dosgi-ri-1.3.1/dosgi_bundles/cxf-dosgi-ri-topology-manager-1.3.1.jar

I need to map these configurations into gf's osgi.properties and can start these bundles in correct order.

Comment by TangYong [ 27/Aug/12 ]

Now, based Step1.1, while I put the selected bundles into GF, DCXF has not ran normally, so I decided to put the original most of bundles on conf\felix.config.properties.append file into GF, integration way is as following:

1 make a new sub-directory called "apachedcxf" under glassfish\modules directory.

2 copy the following bundles into the apachedcxf directory,

com.springsource.org.aopalliance-1.0.0.jar
com.springsource.org.apache.commons.logging-1.1.1.jar
com.springsource.org.jdom-1.1.0.jar
com.springsource.slf4j.api-1.5.10.jar
com.springsource.slf4j.jcl-1.5.10.jar
cxf-bundle-minimal-2.5.2.jar
cxf-dosgi-ri-discovery-local-1.3.1.jar
cxf-dosgi-ri-dsw-cxf-1.3.1.jar
cxf-dosgi-ri-topology-manager-1.3.1.jar
geronimo-activation_1.1_spec-1.1.jar
geronimo-annotation_1.0_spec-1.1.1.jar
geronimo-javamail_1.4_spec-1.2.jar
geronimo-servlet_3.0_spec-1.0.jar
geronimo-ws-metadata_2.0_spec-1.1.3.jar
jetty-all-server-7.4.2.v20110526.jar
neethi-3.0.1.jar
org.apache.servicemix.bundles.asm-3.3_2.jar
org.apache.servicemix.bundles.commons-pool-1.5.4_1.jar
org.apache.servicemix.bundles.joda-time-1.5.2_4.jar
org.apache.servicemix.bundles.opensaml-2.4.1_1.jar
org.apache.servicemix.bundles.wsdl4j-1.6.2_5.jar
org.apache.servicemix.bundles.xmlresolver-1.2_4.jar
org.apache.servicemix.bundles.xmlsec-1.4.5_1.jar
org.apache.servicemix.specs.jaxb-api-2.1-1.9.0.jar
org.apache.servicemix.specs.jaxws-api-2.1-1.9.0.jar
org.apache.servicemix.specs.jsr311-api-1.1.1-1.9.0.jar
org.apache.servicemix.specs.saaj-api-1.3-1.9.0.jar
org.apache.servicemix.specs.stax-api-1.0-1.9.0.jar
org.osgi.enterprise-4.2.0.jar
pax-web-jetty-1.0.3.jar
pax-web-runtime-1.0.3.jar
pax-web-spi-1.0.3.jar
spring-aop-3.0.6.RELEASE.jar
spring-asm-3.0.6.RELEASE.jar
spring-beans-3.0.6.RELEASE.jar
spring-context-3.0.6.RELEASE.jar
spring-core-3.0.6.RELEASE.jar
spring-expression-3.0.6.RELEASE.jar
spring-osgi-core-1.2.1.jar
spring-osgi-extender-1.2.1.jar
spring-osgi-io-1.2.1.jar
xmlschema-core-2.0.1.jar

3 modify the config/osgi.properties file liking the following,
1) add apachedcxf directory into glassfish.osgi.auto.install
glassfish.osgi.auto.install=\
$

{com.sun.aas.installRootURI}modules/endorsed/ \
${com.sun.aas.installRootURI}

modules/osgi-resource-locator.jar \
$

{com.sun.aas.installRootURI}modules/ \
${com.sun.aas.installRootURI}

modules/autostart/ \
$

{com.sun.aas.installRootURI}modules/apachedcxf/

2) add ${apache.dcxf.bundles} into glassfish.osgi.auto.start
glassfish.osgi.auto.start=\
${core.bundles} \
${osgi-ee.bundles} \
${osgi-shell.bundles} \
${apache.dcxf.bundles}

3) define ${apache.dcxf.bundles}
${com.sun.aas.installRootURI}

modules/apachedcxf/com.springsource.org.apache.commons.logging-1.1.1.jar \
$

{com.sun.aas.installRootURI}modules/apachedcxf/com.springsource.org.jdom-1.1.0.jar \
${com.sun.aas.installRootURI}

modules/apachedcxf/spring-core-3.0.6.RELEASE.jar \
...

4) define list of Apache DCXF Bundles whose start levels are copied from felix.config.properties.append
glassfish.osgi.auto.start.level.51= $

{com.sun.aas.installRootURI}modules/apachedcxf/geronimo-annotation_1.0_spec-1.1.1.jar
glassfish.osgi.auto.start.level.52= ${com.sun.aas.installRootURI}

modules/apachedcxf/geronimo-activation_1.1_spec-1.1.jar
glassfish.osgi.auto.start.level.53= $

{com.sun.aas.installRootURI}modules/apachedcxf/geronimo-javamail_1.4_spec-1.2.jar
glassfish.osgi.auto.start.level.54= ${com.sun.aas.installRootURI}

modules/apachedcxf/geronimo-servlet_3.0_spec-1.0.jar
...

5) modify glassfish.osgi.start.level.final propety
glassfish.osgi.start.level.final=95

6) add org.osgi.framework.system.packages.extra [1]
org.osgi.framework.system.packages.extra= org.w3c.dom.traversal
[1]http://cxf.apache.org/dosgi-multi-bundle-setup.html

4 start GF domain and telnet felix shell

5 execute the following,

g! start http://repo1.maven.org/maven2/org/apache/cxf/dosgi/samples/cxf-dosgi-ri-samples-greeter-interface/1.2/cxf-dosgi-ri-samples-greeter-interface-1.2.jar
g! start http://repo1.maven.org/maven2/org/apache/cxf/dosgi/samples/cxf-dosgi-ri-samples-greeter-impl/1.2/cxf-dosgi-ri-samples-greeter-impl-1.2.jar

6 access "http://localhost:9090/greeter?wsdl" and see the remote service's wsdl description successfully.

Althogh the above integration seemed to be successful, there are several following problems needed to be resolved:

(1) still need to confirm the minimal bundles in order to integrate DCXF(Step 1.1's analyse is not enough)
(2) current Apache DCXF's version has a big problem found(service client can not import remote service ) and I have asked the David[2] and commented on DCXF JIRA[3] and I decided to try to firstly integrate dcxf 1.2 version from tomorrow.

[2]https://community.jboss.org/thread/174136
[3]https://issues.apache.org/jira/browse/DOSGI-114

Comment by TangYong [ 27/Aug/12 ]

Now, Glassfish with Apache DCXF 1.2 has integrated successfully!

Using Way is as following,

1 make a sub-directory called "apachedcxf" under glassfish\modules.

2 copy apache dcxf-related bundles[1] into "apachedcxf" directory.
[1]https://github.com/tangyong/gf-dcxf-integration/tree/master/apachedcxf

3 copy and override glassfish\config\osgi.properties using modified osgi.properties[2]
[2]https://github.com/tangyong/gf-dcxf-integration/blob/master/osgi.properties

4 start GF domain and telnet GF Felix Shell

5 According to Distributed OSGi Greeter Demo Walkthrough[3], install and start cxf-dosgi-ri-samples-greeter-interface-1.2.jar and cxf-dosgi-ri-samples-greeter-impl-1.2.jar

6 access "http://localhost:9090/greeter?wsdl" and you can see the wsdl description of exported remote service

7 start another osgi framework with Apache DCXF 1.2(or GF with Apache DCXF 1.2), install and start cxf-dosgi-ri-samples-greeter-interface-1.2.jar and cxf-dosgi-ri-samples-greeter-client-1.2.jar, then input "foobar" on popuped dialog, and you will see the following info,

greetMe("foobar") returns:
Hola foobar
Bonjour foobar
Hoi foobar
Hello foobar

Comment by ancoron [ 27/Aug/12 ]

While I think remote OSGi is something that is really useful there are some other things to look at, as I already have some deeper experience with Apache D-CXF in GlassFish 3.1:

  1. Apache D-CXF doesn't play well with generics (e.g. see https://issues.apache.org/jira/browse/CXF-3613)
  2. Don't we need a different (much simpler) TopologyManager for GlassFish Clusters?
  3. Shouldn't the HTTP endpoint deployment use the default virtual server instead of trying to open yet another port?
  4. Apache D-CXF is quite heavy-weight - consider alternatives like Eclipse ECF (http://wiki.eclipse.org/ECF/Distributed_OSGi_Services) or FuseSource Fabric (http://fuse.fusesource.org/fabric/index, example here: https://github.com/fusesource/fuse/tree/master/fabric/fabric-examples/fabric-camel-dosgi)
  5. Can the existing GMS provide a TopologyManager? Could avoid the extra-cost of ZooKeeper and similar.


From my point of view also the following question matters in production environments:

  1. Use local (same-JVM) service or always go remote (TCP)?


Usually all projects work nice with their published demos but it turns out that most of them just don't work if you have existing services leveraging recent language constructs and "just" want to export them remotely.

Comment by TangYong [ 28/Aug/12 ]

Thanks for your deeper experience very much.

>Apache D-CXF doesn't play well with generics (e.g. see https://issues.apache.org/jira/browse/CXF-3613)
Indeed , Apache DCXF still needed to be improved on some aspects.

>Don't we need a different (much simpler) TopologyManager for GlassFish Clusters?
>Can the existing GMS provide a TopologyManager? Could avoid the extra-cost of ZooKeeper and similar.
Maybe shoal team can explain the point, and about whether ZooKeeper(Nowaday, I only know Zookeeper has been used on Remote Service Discovery) can do the same thing or not, if having more time, we can investigate it and maybe provide a better solution!

>Shouldn't the HTTP endpoint deployment use the default virtual server instead of trying to open yet another port?
Yeah, this is a problem and I will investigate it if having more time. Thanks your suggestion!

>Apache D-CXF is quite heavy-weight - consider alternatives like Eclipse ECF (http://wiki.eclipse.org
>/ECF/Distributed_OSGi_Services) or FuseSource Fabric (http://fuse.fusesource.org/fabric/index, example here: >https://github.com/fusesource/fuse/tree/master/fabric/fabric-examples/fabric-camel-dosgi)

About the point("quite heavy-weight"), I think that Eclipse ECF and FuseSource Fabric maybe will bring more coupling with other framework, and of course, if having more time, I will try to invesitigate and try them.

Comment by TangYong [ 12/Oct/12 ]

Consider deferring implementing this feature for now for the following reasons:

1) need to consider start level because of dcxf self
Maybe need to combine with GLASSFISH-18945

2) distributed osgi runtime is not very important for current glassfish although dosgi is a very excellent improvment for OSGi self(making OSGi have distributed feature liking rmi, corba,...).

3) need to consider integration with other osgi platform related dosgi framework, not only is dcxf, because glassfish also supports other osgi runtime as equinox.

4) integration way is still in progress and maybe needs to be combined with ondemand obr deployment.

Comment by TangYong [ 29/Nov/12 ]

Now, DOSGI-114 [1] has been fixed and next week, DOSGi 1.4 will be released. This release is a big release and I will integrate DOSGi based the release.

[1]: https://issues.apache.org/jira/browse/DOSGI-114

In addition,

>2) distributed osgi runtime is not very important for current glassfish although dosgi is a very excellent improvment for OSGi self(making OSGi have distributed feature liking rmi, corba,...).

In the future, there is a plan to use OSGi/CDI to import OSGi Service from distribute OSGi runtime, So integrating dosgi has turned very important.

--Tang





[GLASSFISH-18910] OSGI Module Status Report Information on Startup Missing from server.log when log level enabled to FINE Created: 17/Jul/12  Updated: 29/Aug/12  Resolved: 29/Aug/12

Status: Closed
Project: glassfish
Component/s: hk2
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: vijay_oracle Assignee: jwells
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

javax.enterprise.system.core.level=FINE set in GF_HOME/domains/domain1/config/logging.properties


Tags: hk2, osgi

 Description   

On startup the server log provides description on OSGI modules and their states. After the HK 2.0 integration the server log is not containing this info.

We use this output to collect OSGI Module statistics on start up.



 Comments   
Comment by mtaube [ 08/Aug/12 ]

Committed revision 55367.

Changed AppServerStartup to @Inject ModulesRegistry. Module status report now prints when javax.enterprise.system.core.level is FINE

+++ nucleus/core/kernel/src/main/java/com/sun/enterprise/v3/server/AppServerStartup.java (working copy)
@@ -115,6 +115,7 @@
@Inject
ServiceLocator locator;

+ @Inject
ModulesRegistry systemRegistry;

Comment by mtaube [ 28/Aug/12 ]

The server log earlier contained module state report once during start-up and once post start-up. Now i see post start-up the module states is being logged 10 times in the log file.

Comment by jwells [ 29/Aug/12 ]

The method is called for each completed level, so it was being called 10 times between level 10 and level 20. Now the code checks for that, and only does the printout when it reaches level 20.





[GLASSFISH-18886] Glassfish exposes the internal modules/osgi bundles for the deployed applications Created: 11/Jul/12  Updated: 19/Sep/14

Status: Open
Project: glassfish
Component/s: classloader, OSGi
Affects Version/s: 3.1
Fix Version/s: 4.1

Type: Bug Priority: Major
Reporter: Ervin88 Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

GNU/Linux 2.6.18-238.el5 x86_64


Tags: eclipse, modules, moxy, osgi

 Description   

A Java EE compliant application server should not expose its internal modules to the applications.

We are using the Eclipse Moxy 2.3.2 in our application that is deployed to a Glassfish 3.1 instance. Moxy 2.3.2 depends on the org.eclipse.persistence.core 2.3.2 artifact. Furthermore, GF 3.1 also contains an org.eclipse.persistence.core(with version 2.2.0) artifact as an osgi bundle in the as-install/glassfish/modules directory. The problem is that the Glassfish/osgi framework exposes the classes to our application from the osgi bundle in the glassfish's modules dir.






[GLASSFISH-18492] [osgi/http] InitParams for Servlets installed via OSGi using HttpService are not correctly processed by web container Created: 10/Mar/12  Updated: 01/Apr/12  Resolved: 01/Apr/12

Status: Resolved
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: 3.1.1
Fix Version/s: 4.0

Type: Bug Priority: Major
Reporter: daniel_yokomizo Assignee: Sanjeeb Sahoo
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Java Archive File osgi-http.jar    
Tags: error_handling, init, osgi, servlet

 Description   

I'm using a HttpServlet deployed using OSGi's HttpService. It works normally but I tried to disable the default error page for it's responses using and org.glassfish.web.isDefaultErrorPageEnabled=false (as described in GLASSFISH-11423). It didn't work, so I decided to debug the issue (because the init parameter was present).

During the debug I discovered that:

1. StandardHostValve uses findInitParameter(Constants.IS_DEFAULT_ERROR_PAGE_ENABLED_INIT_PARAM) in line 229 to get the init parameter value and parse it.
2. StandardWrapper.findInitParameter(String) tries to search a parameters instance variable. This variable is an empty HashMap.
3. The actual subclass is OSGiServletWrapper.
4. The OSGiServletConfig associated with the OSGiServletWrapper (i.e. the "instance" instance variable) has an initParams instance variable with this value:

{org.glassfish.web.isDefaultErrorPageEnabled=false}

.



 Comments   
Comment by Sanjeeb Sahoo [ 11/Mar/12 ]

Thanks for reporting. Didn't realize that the findInitParam...() methods were not delegating to their get... equivalents. Could you try the attached patch and let me know if this fixes your issue. I could then commit the fix and make a new release of osgi-http module.

Comment by daniel_yokomizo [ 13/Mar/12 ]

Thanks for the prompt response. It worked for me, now I get an empty response (with the correct status line) instead of the error page.

Comment by Sanjeeb Sahoo [ 13/Mar/12 ]

Sending osgi-http/RELEASENOTE.txt
Sending osgi-http/src/main/java/org/glassfish/osgihttp/OSGiServletConfig.java
Sending osgi-http/src/main/java/org/glassfish/osgihttp/OSGiServletWrapper.java
Transmitting file data ...
Committed revision 52906.

Will mark the bug resolved after integrating it with glassfish build.

Comment by Sanjeeb Sahoo [ 01/Apr/12 ]

Integrated osgi-http 1.0.5 in gf trunk in svn rev #53292.





[GLASSFISH-18381] JPA OSGi WAB redployment hangs Glassfish and unable to shutdown Created: 20/Feb/12  Updated: 25/Mar/13  Resolved: 25/Mar/13

Status: Resolved
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: 4.0_b82_EE7MS7
Fix Version/s: 4.0_b82_EE7MS7

Type: Bug Priority: Critical
Reporter: blackbeltdev Assignee: Sanjeeb Sahoo
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 64-bit

java version "1.6.0_29"
Java(TM) SE Runtime Environment (build 1.6.0_29-b11)
Oracle JRockit(R) (build R28.2.0-79-146777-1.6.0_29-20111005-1808-windows-x86_64, compiled mode)


Attachments: Zip Archive AddressBook.zip     Java Archive File cpms-web-static.jar     File cpms-web.war    
Tags: 3_1_2-exclude, 3_1_2-next, jpa, osgi, osgi-javaee

 Description   

Re-deploying a JPA enabled WAB bundle causes Glassfish to hang. I noticed this interesting message in the logs:

[#|2012-02-20T09:37:21.989-0600|INFO|glassfish3.1.2|org.glassfish.osgijpa|_ThreadID=17;_ThreadName=Thread-4;|Deferring refresh to framework restart, so enhanced bytes won't come into effect until then for bundle 292 if there are existing wires to this bundle.|#]

This is completely reproducible every time:
1) Start glassfish
2) Deploy WAB (works fine)
3) Edit source file (e.g. add println/logging)
4) Re-deploy
5) Hangs with logging similar to the below
6) Unable to stop glassfish outside of killing Java process

From what I can tell it looks like it is stuck on the following thread:

Stack Trace
admin-thread-pool-4848(1) [131] (WAITING)
java.lang.Object.wait line: 485
org.apache.felix.framework.Felix.acquireGlobalLock line: 4943
org.apache.felix.framework.StatefulResolver.resolve line: 219
org.apache.felix.framework.BundleWiringImpl.searchDynamicImports line: 1539
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation line: 1439
org.apache.felix.framework.BundleWiringImpl.access$400 line: 72
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass line: 1843
java.lang.ClassLoader.loadClass line: 247
com.sun.enterprise.container.common.GenericAdminAuthenticator.loginAsAdmin line: 0
com.sun.enterprise.v3.admin.AdminAdapter.authenticate line: 268
com.sun.enterprise.v3.admin.AdminAdapter.authenticate line: 310
com.sun.enterprise.v3.admin.AdminAdapter.service line: 210
com.sun.grizzly.tcp.http11.GrizzlyAdapter.service line: 179
com.sun.enterprise.v3.server.HK2Dispatcher.dispath line: 117
com.sun.enterprise.v3.services.impl.ContainerMapper$Hk2DispatcherCallable.call line: 354
com.sun.enterprise.v3.services.impl.ContainerMapper.service line: 195
com.sun.grizzly.http.ProcessorTask.invokeAdapter line: 849
com.sun.grizzly.http.ProcessorTask.doProcess line: 746
com.sun.grizzly.http.ProcessorTask.process line: 1045
com.sun.grizzly.http.DefaultProtocolFilter.execute line: 228
com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter line: 137
com.sun.grizzly.DefaultProtocolChain.execute line: 104
com.sun.grizzly.DefaultProtocolChain.execute line: 90
com.sun.grizzly.http.HttpProtocolChain.execute line: 79
com.sun.grizzly.ProtocolChainContextTask.doCall line: 54
com.sun.grizzly.SelectionKeyContextTask.call line: 59
com.sun.grizzly.ContextTask.run line: 71
com.sun.grizzly.util.AbstractThreadPool$Worker.doWork line: 532
com.sun.grizzly.util.AbstractThreadPool$Worker.run line: 513
java.lang.Thread.run line: 662

[#|2012-02-20T09:37:16.167-0600|INFO|glassfish3.1.2|org.glassfish.osgiejb|_ThreadID=17;_ThreadName=Thread-4;|removedService: Found 1 no. of EJBs|#]

[#|2012-02-20T09:37:18.462-0600|INFO|glassfish3.1.2|org.glassfish.osgijavaeebase|_ThreadID=17;_ThreadName=Thread-4;|Deleted C:\Users\KIRK~1.RAS\AppData\Local\Temp\osgiapp3320546087592904764|#]

[#|2012-02-20T09:37:18.464-0600|INFO|glassfish3.1.2|org.glassfish.osgijavaeebase|_ThreadID=17;_ThreadName=Thread-4;|Undeployed bundle com.textura.cpms.web [292]|#]

[#|2012-02-20T09:37:21.233-0600|INFO|glassfish3.1.2|org.glassfish.osgijpa|_ThreadID=17;_ThreadName=Thread-4;|Bundle having id 292 is a JPA bundle|#]

[#|2012-02-20T09:37:21.350-0600|INFO|glassfish3.1.2|org.glassfish.osgijpa|_ThreadID=17;_ThreadName=Thread-4;|Exploded bundle com.textura.cpms.web [292] at C:\Users\KIRK~1.RAS\AppData\Local\Temp\osgiapp5360629438350331033 |#]

[#|2012-02-20T09:37:21.551-0600|INFO|glassfish3.1.2|org.glassfish.osgijpa|_ThreadID=17;_ThreadName=Thread-4;|Source = C:\Users\KIRK~1.RAS\AppData\Local\Temp\osgiapp5360629438350331033\WEB-INF\classes, Target = C:\Users\KIRK~1.RAS\AppData\Local\Temp\enhanced-osgiapp8372524464557779997\WEB-INF\classes|#]

[#|2012-02-20T09:37:21.912-0600|WARNING|glassfish3.1.2|org.glassfish.osgijpa|_ThreadID=17;_ThreadName=Thread-4;|Unable to delete C:\Users\KIRK~1.RAS\AppData\Local\Temp\osgiapp5360629438350331033|#]

[#|2012-02-20T09:37:21.977-0600|INFO|glassfish3.1.2|org.glassfish.osgijpa|_ThreadID=25;_ThreadName=Thread-4;|Deleted C:\Users\KIRK~1.RAS\AppData\Local\Temp\enhanced-osgiapp8372524464557779997 |#]

[#|2012-02-20T09:37:21.989-0600|INFO|glassfish3.1.2|org.glassfish.osgijpa|_ThreadID=17;_ThreadName=Thread-4;|Deferring refresh to framework restart, so enhanced bytes won't come into effect until then for bundle 292 if there are existing wires to this bundle.|#]

[#|2012-02-20T09:37:21.989-0600|INFO|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=17;_ThreadName=Thread-4;|Updated C:\dev\java\tools\glassfish-3.1.2-b23\glassfish3\glassfish\domains\domain1\autodeploy\bundles\cpms-web.war|#]

[#|2012-02-20T09:37:21.993-0600|INFO|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=17;_ThreadName=Thread-4;|Started bundle: file:/C:/dev/java/tools/glassfish-3.1.2-b23/glassfish3/glassfish/domains/domain1/autodeploy/bundles/cpms-web.war|#]

[#|2012-02-20T09:37:40.346-0600|INFO|glassfish3.1.2|org.glassfish.osgijavaeebase|_ThreadID=19;_ThreadName=Thread-4;|Expanded at file:/C:/Users/KIRK~1.RAS/AppData/Local/Temp/osgiapp1648809821027798109/|#]

Nothing happens for a long time until...

[#|2012-02-20T10:43:40.474-0600|WARNING|glassfish3.1.2|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=15;_ThreadName=Thread-4;|GRIZZLY0023: Interrupting idle Thread: http-thread-pool-8080(2).|#]

[#|2012-02-20T10:43:41.477-0600|WARNING|glassfish3.1.2|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=15;_ThreadName=Thread-4;|GRIZZLY0023: Interrupting idle Thread: http-thread-pool-8080(4).|#]

[#|2012-02-20T10:43:43.479-0600|WARNING|glassfish3.1.2|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=15;_ThreadName=Thread-4;|GRIZZLY0023: Interrupting idle Thread: http-thread-pool-8080(1).|#]

[#|2012-02-20T10:44:32.144-0600|WARNING|glassfish3.1.2|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=14;_ThreadName=Thread-4;|GRIZZLY0023: Interrupting idle Thread: admin-thread-pool-4848(1).|#]

[#|2012-02-20T10:44:33.144-0600|WARNING|glassfish3.1.2|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=14;_ThreadName=Thread-4;|GRIZZLY0023: Interrupting idle Thread: admin-thread-pool-4848(1).|#]

[#|2012-02-20T10:44:34.144-0600|WARNING|glassfish3.1.2|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=14;_ThreadName=Thread-4;|GRIZZLY0023: Interrupting idle Thread: admin-thread-pool-4848(1).|#]

[#|2012-02-20T10:44:35.144-0600|WARNING|glassfish3.1.2|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=14;_ThreadName=Thread-4;|GRIZZLY0023: Interrupting idle Thread: admin-thread-pool-4848(1).|#]

[#|2012-02-20T10:44:35.587-0600|SEVERE|glassfish3.1.2|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=26;_ThreadName=Thread-4;|service exception
java.lang.RuntimeException: ClientAbortException: java.io.IOException: Connection aborted by peer
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:246)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:179)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at com.sun.enterprise.v3.services.impl.ContainerMapper$Hk2DispatcherCallable.call(ContainerMapper.java:355)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:849)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:747)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1046)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:228)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:105)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:91)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:56)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)
Caused by: ClientAbortException: java.io.IOException: Connection aborted by peer
at com.sun.grizzly.tcp.http11.GrizzlyOutputBuffer.doFlush(GrizzlyOutputBuffer.java:439)
at com.sun.grizzly.tcp.http11.GrizzlyOutputBuffer.flush(GrizzlyOutputBuffer.java:405)
at com.sun.grizzly.tcp.http11.GrizzlyOutputStream.flush(GrizzlyOutputStream.java:140)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:243)
... 18 more
Caused by: java.io.IOException: Connection aborted by peer
at sun.nio.ch.SocketDispatcher.write1(Native Method)
at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:58)
at sun.nio.ch.IOUtil.write(IOUtil.java:199)
at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:334)
at com.sun.grizzly.util.OutputWriter.flushChannel(OutputWriter.java:108)
at com.sun.grizzly.util.OutputWriter.flushChannel(OutputWriter.java:76)
at com.sun.grizzly.http.SocketChannelOutputBuffer.flushChannel(SocketChannelOutputBuffer.java:417)
at com.sun.grizzly.http.SocketChannelOutputBuffer.flushBuffer(SocketChannelOutputBuffer.java:489)
at com.sun.grizzly.http.SocketChannelOutputBuffer.flush(SocketChannelOutputBuffer.java:467)
at com.sun.grizzly.http.ProcessorTask.action(ProcessorTask.java:1276)
at com.sun.grizzly.tcp.Response.action(Response.java:268)
at com.sun.grizzly.tcp.http11.GrizzlyOutputBuffer.doFlush(GrizzlyOutputBuffer.java:434)
at com.sun.grizzly.tcp.http11.GrizzlyOutputBuffer.flush(GrizzlyOutputBuffer.java:405)
at com.sun.grizzly.tcp.http11.GrizzlyOutputStream.flush(GrizzlyOutputStream.java:140)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:243)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:179)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at com.sun.enterprise.v3.services.impl.ContainerMapper$Hk2DispatcherCallable.call(ContainerMapper.java:354)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:849)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:746)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1045)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:228)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
... 5 more

I have attached the source along with the bundles.

1) Host bundle for application (uses Vaadin 6.7.5)
2) Static resources as Bundle Fragment



 Comments   
Comment by blackbeltdev [ 20/Feb/12 ]

FYI.. I don't notice this behavior with non-JPA WAB bundles. I'm able to redeploy WABs back to back with no problem.

Comment by Joe Di Pol [ 20/Feb/12 ]

3.1.2 has wrapped up. Tagging for consideration in next update.

Comment by Hong Zhang [ 21/Feb/12 ]

assign to sahoo for initial evaluation

Comment by blackbeltdev [ 21/Feb/12 ]

Hmmm...

What's interesting is that the eclipsecon2011 demo doesn't exhibit this behavior. I'm able to continuously update the ejb_service bundle without having any issues. Maybe its related to deploying everything as part of the WAB like I did rather than split code between the API, Impl, and Web bundles in eclipsecon2011 demo.

On a related note I'd like to know how to split the eclipsecon2011 bundles further. I'm working on a long email to post to the users@glassfish.java.net email list.

Basically I'd like to know how to split the EJB Service implementation and JPA entities into their own bundles. In other words I'd like to create a persistence bundle that contains the entities (and persistence.xml) only and create another EJB service bundle that consumes the persistence bundle rather than package the service layer and entities together for increased modularity.

Comment by Sanjeeb Sahoo [ 21/Feb/12 ]

Checkout https://svn.java.net/svn/glassfish~svn/trunk/fighterfish/sample/uas and see how to split EJBs, JPAs and WABs have been split into separate bundles.

Comment by Sanjeeb Sahoo [ 21/Feb/12 ]

Your WAB depends on so many other packages and you never mentioned about them. I had to deploy groovy-all-1.8.6.jar, slf4j-api-1.6.1.jar, slf4j-nop-1.6.1.jar, vaadin-6.7.5.jar before I could deploy your WAB. Anyway, after doing all these, I was able to successfully deploy and redeploy the WAB. I didn't notice any hangI tried accessing app/address-book/ and saw some JPA query getting executed in server, so I am assuming the app is more-or-less working fine.

Did you try to undeploy while the app was still getting deployed? See GLASSFISH-18159 for potential deadlock in such a situation. Deployment is asynchronous where as undeployment is synchronous. So, you must wait for a message like the one shown below to appear before proceeding to use the app:
deployed bundle com.textura.cpms.web [289] at file:/tmp/osgiapp8158913360060872663/

Comment by blackbeltdev [ 21/Feb/12 ]

Sorry about not mentioning the dependencies. I tried to be as precise as possible and forgot the basics!

The other thing I should have mentioned that the method I used to deploy was to copy the WAR file to the autodeploy/bundle directory. The "redeploy" method was to simply overwrite the WAR file with a newer version.

Like I said above replacing the EJB JAR file from the EcliipseCon sample code did not have this problem. It only seems to be a problem with WABs that contain EJB/JPA probably due to the amount of time involved, i.e. my other simple WABs undeploy so fast it didn't run into the deadlock condition.

I will try to undeploy and deploy as distinct steps and see what happens.

Comment by blackbeltdev [ 21/Feb/12 ]

I think you hit the nail on the head. If I delete the WAR, wait, and then copy the file to autodeploy then there is no problem. However if I replace the existing file it will deadlock. You can see these threads are simultaneously deploying and undeploying (notice two threads are waiting on Felix.acquireBundleLock):

Stack Trace
fileinstall-C:\dev\java\tools\glassfish-3.1.2-b23\glassfish3\glassfish\domains\domain1/autodeploy/bundles/ [65] (WAITING)
java.lang.Object.wait line: 485
org.apache.felix.framework.Felix.acquireBundleLock line: 4870
org.apache.felix.framework.Felix.startBundle line: 1744
org.apache.felix.framework.BundleImpl.start line: 944
org.apache.felix.fileinstall.internal.DirectoryWatcher.process line: 1175
org.apache.felix.fileinstall.internal.DirectoryWatcher.process line: 1153
org.apache.felix.fileinstall.internal.DirectoryWatcher.processAllBundles line: 1146
org.apache.felix.fileinstall.internal.DirectoryWatcher.process line: 456
org.apache.felix.fileinstall.internal.DirectoryWatcher.run line: 263

Stack Trace
FelixFrameworkWiring [131] (WAITING)
sun.misc.Unsafe.park line: not available [native method]
java.util.concurrent.locks.LockSupport.park line: 156
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt line: 811
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly line: 969
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly line: 1281
java.util.concurrent.FutureTask$Sync.innerGet line: 218
java.util.concurrent.FutureTask.get line: 83
org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer.removedBundle line: 183
org.osgi.util.tracker.BundleTracker$Tracked.customizerRemoved line: 508
org.osgi.util.tracker.BundleTracker$Tracked.customizerRemoved line: 424
org.osgi.util.tracker.AbstractTracked.untrack line: 352
org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged line: 464
org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback line: 868
org.apache.felix.framework.util.EventDispatcher.fireEventImmediately line: 789
org.apache.felix.framework.util.EventDispatcher.fireBundleEvent line: 514
org.apache.felix.framework.Felix.fireBundleEvent line: 4244
org.apache.felix.framework.Felix.stopBundle line: 2351
org.apache.felix.framework.Felix$RefreshHelper.stop line: 4629
org.apache.felix.framework.Felix.refreshPackages line: 3951
org.apache.felix.framework.FrameworkWiringImpl.run line: 172
java.lang.Thread.run line: 662

Stack Trace
pool-8-thread-1 [71] (WAITING)
java.lang.Object.wait line: 485
org.apache.felix.framework.Felix.acquireGlobalLock line: 4943
org.apache.felix.framework.StatefulResolver.resolve line: 219
org.apache.felix.framework.BundleWiringImpl.searchDynamicImports line: 1539
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation line: 1439
org.apache.felix.framework.BundleWiringImpl.access$400 line: 72
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass line: 1843
java.lang.ClassLoader.loadClass line: 247
java.lang.ClassLoader.defineClass1 line: not available [native method]
java.lang.ClassLoader.defineClassCond line: 631
java.lang.ClassLoader.defineClass line: 615
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass line: 2128
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation line: 1432
org.apache.felix.framework.BundleWiringImpl.access$400 line: 72
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass line: 1843
java.lang.ClassLoader.loadClass line: 247
java.lang.Class.getDeclaredMethods0 line: not available [native method]
java.lang.Class.privateGetDeclaredMethods line: 2427
java.lang.Class.getDeclaredMethods line: 1791
org.glassfish.apf.impl.ComponentDefinition.initializeMethods line: 132
org.glassfish.apf.impl.ComponentDefinition.<init> line: 76
org.glassfish.apf.impl.JavaEEScanner.getComponentInfo line: 70
org.glassfish.apf.impl.AnnotationProcessorImpl.process line: 177
org.glassfish.apf.impl.AnnotationProcessorImpl.process line: 134
com.sun.enterprise.deployment.archivist.Archivist.processAnnotations line: 598
com.sun.enterprise.deployment.archivist.Archivist.readAnnotations line: 442
com.sun.enterprise.deployment.archivist.Archivist.readAnnotations line: 429
com.sun.enterprise.deployment.archivist.Archivist.readRestDeploymentDescriptors line: 405
com.sun.enterprise.deployment.archivist.Archivist.readDeploymentDescriptors line: 380
com.sun.enterprise.deployment.archivist.Archivist.open line: 243
com.sun.enterprise.deployment.archivist.Archivist.open line: 252
com.sun.enterprise.deployment.archivist.Archivist.open line: 213
com.sun.enterprise.deployment.archivist.ApplicationFactory.openArchive line: 165
org.glassfish.javaee.core.deployment.DolProvider.load line: 185
org.glassfish.javaee.core.deployment.DolProvider.load line: 94
com.sun.enterprise.v3.server.ApplicationLifecycle.loadDeployer line: 827
com.sun.enterprise.v3.server.ApplicationLifecycle.setupContainerInfos line: 769
com.sun.enterprise.v3.server.ApplicationLifecycle.deploy line: 368
com.sun.enterprise.v3.server.ApplicationLifecycle.deploy line: 240
org.glassfish.osgijavaeebase.OSGiDeploymentRequest.deploy line: 183
org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute line: 118
org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy line: 121
org.glassfish.osgijavaeebase.OSGiContainer.deploy line: 154
org.glassfish.osgijavaeebase.JavaEEExtender.deploy line: 107
org.glassfish.osgijavaeebase.JavaEEExtender.access$200 line: 61
org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call line: 151
org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call line: 148
java.util.concurrent.FutureTask$Sync.innerRun line: 303
java.util.concurrent.FutureTask.run line: 138
java.util.concurrent.ThreadPoolExecutor$Worker.runTask line: 886
java.util.concurrent.ThreadPoolExecutor$Worker.run line: 908
java.lang.Thread.run line: 662

Comment by Sanjeeb Sahoo [ 21/Feb/12 ]

I am unable to reproduce even when I just deploy/update the war using autodpeloy/bundles/.

Comment by blackbeltdev [ 21/Feb/12 ]

With multi-threaded code and machine differences there's always the possibility of different runtime characteristics. I remember when I got my first dual core machine an application that worked fine on my single core machine started deadlocking on a regular basis

Now I'm running with Intel Quad Core Q9300 @ 2.53 GHz

Comment by Sanjeeb Sahoo [ 21/Feb/12 ]

Those are always possibilities for MT issues. You should wait for GLASSFISH-18159 to be integrated to see if that makes any difference.

Comment by blackbeltdev [ 21/Feb/12 ]

Will do. I tried it about 10 times so far and if I 'delete WAR, wait, copy file' it works every time. If I just replace the file it deadlocks every time.

BTW is 'users@glassfish.java.net' still the best place to post questions or should I use the Glassfish forums. I just sent an email about splitting up the EJB/JPA from the EclipseCon demo into separate packages so the entities and service are more modular.

Thanks for your help!

Comment by Sanjeeb Sahoo [ 21/Feb/12 ]

Did you checkout the sample I had mentioned in an earlier comment in this bug? Did it not answer your question abut how to split into smaller bundles?

Comment by blackbeltdev [ 21/Feb/12 ]

Arg sorry I missed that one. I'll check it out!

Thanks again!

Comment by blackbeltdev [ 21/Feb/12 ]

I was able to get the fighterfish UAS sample working! I had to make a couple of maven changes and after some trial and error figured out I need to update

$GLASSFISH_HOME/glassfish/config/osgi.properties:
org.glassfish.osgijpa.extension.useHybridPersistenceProviderResolver=true

As an OSGi noob even after (mostly) reading "OSGi in Depth" I foundthe JPA setup extremely confusing and non-intuitive (not Glassfish specific).

Maybe add a link to the "fighterfish" samples here as the JPA section is a little too brief on how to go about splitting up the entities and EJBs:
http://glassfish.java.net/public/GF-OSGi-Features.pdf

I would also suggestion that you update your excellent OSGi EclipseCon tutorial to use the "fighterfish" sample instead (which is much more realistic) I think it would help the new users tremendously to get started on Enterprise OSGi which is still IMO not very well documented with lots of conflicting advice (outside of Glassfish I mean).

What we really need is the PetClinic Sample ported to hybrid JavaEE/OSGi with CDI/JPA/OSGi.

Not having Hibernate JPA support kind of hurts us from adopting Glassfish. Is there any timeline for implementing Hibernate in the near term? I realize I can embed Hibernate libraries and entities in the bundle and make it work (kind of like the 'ejbservice' sample does) but that defeats some of the modularization benefits of OSGi.

Thanks again!

Comment by Sanjeeb Sahoo [ 22/Feb/12 ]

What changes did you have to do to the pom.xml to get it to work? I didn't anticipate them. Pl mention that so that I can fix them. May be by creating a bug under osgi-javaee category here.

I will fix the document to reference the sample from each technology section.

I don't know if I have the time to redo the eclipsecon tutorial - may be when I get to present them next time, I will do them. It takea a looo...t of time to create a high quality screencast.

I totally agree about having a petstore type hybrid app leveraging osgi/cdi/ejb/jpa. It comes down to resource availability.

Hibernate dev has not been very helpful in making their software OSGi-ready. I don't have the time to help them, so I don't complain. Your best bet is to embed Hibernate in jpa bundles.

Thanks much,
Sahoo

Comment by blackbeltdev [ 23/Feb/12 ]

Thank you Sahoo. You have been very helpful. The pom changes were mostly unique to our location and a few minor changes to eliminate some duplication. I think the biggest changes I made was to add

<relativePath>../../parent-pom/pom.xml</relativePath>

to each project so I didn't need to install artifacts in local maven repo.

And parent-pom had 1.0.1-SNAPSHOT rather than 1.0.0-SNAPSHOT

<version>1.0.1-SNAPSHOT</version>

Now that I have a working project my understanding has greatly increased. Maybe I can take a stab at a newbie guide since its fresh in my head. I totally missed the appendix had the samples listed already.

I went though the exercise to embed Hibernate in a bundle and got that working. I now have a greater appreciation of the difficulty. That was painful! It was really difficult to get maven/bnd to create the proper manifest file (I had to hack it a bit to make it work).

One last thing that wasn't clear to me is about JPA bootstrapping. In the ejbservice1 example you used managed JPA deployment which allowed you to simplify coding:

    @PersistenceContext
    private EntityManager em;

whereas in ejbservice2 you used unmanaged JPA and injected EntityManagerFactory

    @Inject
    @OSGiService(dynamic = true, serviceCriteria = "(persistence-unit=sample.uas.entities)")
    private EntityManagerFactory emf;

so the code becomes more brittle (i.e. have to manually create/close EntityManager):


    EntityManager em = emf.createEntityManager();
    try {
    } finally {
        em.close();
    }

I was wondering if this is the only option or is it possible to use managed JPA with CDI to inject EntityManager in the EJB similar to ejbservice1 example? Something like (doesn't work):


    @Inject
    @OSGiService(dynamic = true, serviceCriteria = "(persistence-unit=sample.uas.entities)")
    private EntityManager em;

In the Enterprise OSGi in Action book they use managed JPA with declarative transactions exclusively in their examples (Apache Aries) using Blueprint, e.g.

package fancyfoods.persistence;

public class InventoryImpl implements Inventory {

    private EntityManager em;

    public void setEntityManager(EntityManager em) {
        this.em = em;
    }
}

        <bean
                id="inventory"
                class="fancyfoods.persistence.InventoryImpl">
                <tx:transaction
                        method="*"
                        value="Required" />
                <jpa:context
                        property="entityManager"
                        unitname="fancyfoods" />
        </bean>

So I'm hopeful this is possible to do with CDI as well.

Thanks again

References:

http://aries.apache.org/modules/jpaproject.html
http://www.manning.com/cummins/SourceCodeEnterpriseOSGiinAction.zip

Comment by Sanjeeb Sahoo [ 24/Feb/12 ]

I would have liked you to raise general questions unrelated to this issue in our mailing list so that they could benefit others. Anyway, I will answer them here since you have asked so meticulously. If you don't want to manage the lifecycle of EntityManager while injecting EMF as a service, I suggest you take a look the following code which uses interceptors to localise the lifecycle management:

https://svn.java.net/svn/glassfish~svn/trunk/fighterfish/test/testapp/test.app16.mdb/src/main/java/org/glassfish/fighterfish/test/app16/mdb/TestApp16MDB_BMT.java

Pl ask related questions in forum. I am traveling now, so expect some delays in replies.

Thanks,
Sahoo

Comment by TangYong [ 13/Oct/12 ]

I think that because GLASSFISH-18159 should have been integreated into current trunk, it is time to re-back the issue and next week, firstly, I will spend some time to see whether the problem will be reproduced.

Comment by TangYong [ 25/Mar/13 ]

For the issue, I have confirmed it in depth today using v4 SNAPSHOT as following:

1. About re-producing steps in description

Firstly, re-producing steps in description are not very enough. And by investigations many times, right steps are as following:

[Precondition]: the means of "re-deploy" should be directly putting bundles related the issue into "glassfish4\glassfish\domains\domain1\autodeploy\bundles" . (Here, I assumed that the user used domain1 only not clustering scene or used multi-domains scene)

[Steps]
1) asadmin start-domain domain1
2) asadmin start-database
3) putting the following bundles into autodeploy\bundles

  • slf4j-jcl-1.6.4.jar
  • slf4j-api-1.6.4.jar
  • com.springsource.org.apache.commons.logging-1.1.1.jar
  • groovy-all-1.8.6.jar
  • vaadin-6.7.5.jar
  • cpms-web-static.jar[1]
  • cpms-web.war
    [1]: you can also firstly put cpms-web.war, then put cpms-web-static.jar, and executing "asadmin osgi update <WAB's bundle id>". I adopted this way.

Noting: please do not put jcl-over-slf4j-1.6.4.jar into autodeploy\bundles, because this will produce a conflict with slf4j-jcl-1.6.4.jar and cause a StackOverflowError while you accessed the vaadin application client.

BTW: In reality, these dependent bundles needed not to be deployed as OSGi bundle alone, and right doing is to make them as inner class path or embed them into the war's inner class path.

In addition, the demo itself is very interesting and uses fragment(cpms-web-static.jar) skill to attach vaadin's themes including widgetsets into host bundle(cpms-web.war) in order to reach dynamic themes switching(I guess) in the future.

4) accessing "http://localhost:8080/app/address-book/" and should be fine

5) modifying cpms-web.war's source(eg. I changed the war's servlet mapping name from address-book into address-book1), then, executing "mvn clean install"

6) replacing the cpms-web.war in autodeploy\bundles with new built cpms-web.war based 5)

2 About the "Hangs with logging similar to the below"
After executing 6), I have not seen any "Hangs with logging similar to the below", however, in server.log, there are the following exceptions:

[2013-03-25T16:35:23.156+0900] [glassfish 4.0] [WARNING] [] [org.glassfish.osgijavaeebase] [tid: _ThreadID=96 _ThreadName=pool-19-thread-1] [timeMillis: 1364196923156] [levelValue: 900] [[
Failed to deploy bundle com.textura.cpms.web [301]
org.glassfish.osgijavaeebase.DeploymentException: Deployment of com.textura.cpms.web [301] failed because of following reason: Failed while deploying bundle com.textura.cpms.web [301] : java.nio.channels.ClosedByInterruptException
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:127)
at org.glassfish.osgijavaeebase.OSGiContainer.deploy(OSGiContainer.java:154)
at org.glassfish.osgijavaeebase.JavaEEExtender.deploy(JavaEEExtender.java:109)
at org.glassfish.osgijavaeebase.JavaEEExtender.access$200(JavaEEExtender.java:61)
at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:153)
at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:150)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
Caused by: java.nio.channels.ClosedByInterruptException
at java.nio.channels.spi.AbstractInterruptibleChannel.end(AbstractInterruptibleChannel.java:202)
at java.nio.channels.Channels$ReadableByteChannelImpl.read(Channels.java:387)
at com.sun.enterprise.util.io.FileUtils.copy(FileUtils.java:952)
at org.glassfish.internal.deployment.GenericHandler.expand(GenericHandler.java:100)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.expandIfNeeded(OSGiDeploymentRequest.java:259)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.prepare(OSGiDeploymentRequest.java:154)
at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:117)
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:123)
... 10 more
]]

At the same time, after I executed "asadmin stop-domain", I can stop glassfish normally and need not to kill the java process from outside.

So, My suggestion is that
1. please blackbeltdev sees the above my confirmation and tried current v4 as possible
2. if not happening on v4, please sahoo closed the issue.
3. about the exception I mentioned, whether needing to re-open an issue?

Thanks
--Tang

Comment by Sanjeeb Sahoo [ 25/Mar/13 ]

Tang,

The fix made in GLASSFISH-18159 means we won't deadlock, but we introduced a timeout functionality. The interrupted exception suggests some other thread interrupted the deployment process because of timeout. See the log file closely to see if there is any message to this effect. The default value for timeout is 10 seconds. See GLASSFISH-20023 to see how you can change it.

Sahoo

Comment by TangYong [ 25/Mar/13 ]

Sahoo,

I am sorry for forgetting to say a point:

The exception can not be re-produced after I applied GLASSFISH-19688, and I felt a litter curious.

So, whether can close the issue?

In addition,

> See GLASSFISH-20023 to see how you can change it.
Your means is whether an user can set the value of "org.glassfish.osgijavaeebase.deployment.timeout" except in osgi.proerties file?

If such being the case, we should create a new feature to resolve it.

Thanks
--Tang

Comment by Sanjeeb Sahoo [ 25/Mar/13 ]

If you can't reproduce, then close the issue.

Comment by TangYong [ 25/Mar/13 ]

The issue can not be re-produced after fixing GLASSFISH-19688 which will be fixed in 4.0_b82_EE7MS7.

If seeing the issue again in the future, I will re-open the issue.





[GLASSFISH-18361] GlassFish OSGI Web Console is not available when GlassFish is installed on custom ports Created: 14/Feb/12  Updated: 12/Feb/13

Status: Open
Project: glassfish
Component/s: OSGi
Affects Version/s: 3.1.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: dkroot Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

GlassFish 3.1.1, Java EE SDK 6 u3 running on JDK 6, Mac OS X 10.6.8 or Windows Server 2003 R2 SP2


Tags: 3_1_2-exclude, 3_1_2-next, admin-gui, osgi

 Description   

Test case:
1. Install either 3.1.1 standalone or Java EE SDK.
2. Select custom ports for HTTP service and Admin service. For example: 1234 and 1235.
3. Run an update tool, install:
glassfish-osgi-gui Application Servers 3.1.1-12
glassfish-osgi-feature-pack Application Servers 3.1.1-12
glassfish-osgi-incorporation Application Servers 3.1.1-12

4. Start the domain

Expected:
OSGi Web Console is available either via Admin Console > server > OSGi Console or via http://localhost:1234/osgi/system/console/ per the documentation.

Actual:
Admin console displays "can't contact server at localhost:8080" in Firefox. The direct OSGi Web Console link displays 404.

Workaround:
Applied workaround from http://java.net/jira/browse/GLASSFISH-18228. The direct link is functional now. However, the Admin console still displays the same error message.



 Comments   
Comment by Joe Di Pol [ 17/Feb/12 ]

Too late to address in 3.1.2. Tagging for consideration in next release.

Comment by Anissa Lam [ 12/Feb/13 ]

Request Sahoo to do the evaluation. I am not sure if this need to be addressed for 4.0, and what needs to be done in the console side. thanks.





[GLASSFISH-18345] Invalid OSGi web fragment missing Bundle-Manifest corrupts glassfish installation Created: 09/Feb/12  Updated: 09/Feb/12  Resolved: 09/Feb/12

Status: Closed
Project: glassfish
Component/s: admin, classloader, configuration, deployment, OSGi, OSGi-JavaEE, web_container
Affects Version/s: 3.1.2_b19, 3.1.2_b20
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: blackbeltdev Assignee: Sanjeeb Sahoo
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 64-bit

java version "1.6.0_29"
Java(TM) SE Runtime Environment (build 1.6.0_29-b11)
Oracle JRockit(R) (build R28.2.0-79-146777-1.6.0_29-20111005-1808-windows-x86_64, compiled mode)


Tags: fragment, osgi, wab

 Description   

I was trying to follow the tutorial from the section named "4.6 Static Resources and WAB" to deploy host.war and fragment.jar to Glassfish 3.1.2b19/20 from here:

http://glassfish.java.net/public/GF-OSGi-Features.pdf

I found out that I was able to corrupt the entire installation by simply adding fragment.jar to the autodeploy\bundle folder.

By tailing the logs you can see that it installed ok:

[#|2012-02-07T11:14:36.857-0600|INFO|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=17;_ThreadName=Thread-4;|Installed C:\dev\java\tools\glassfish-3.1.2-b20\glassfish3\glassfish\domains\domain1\autodeploy\bundles\fragment.jar|#]

But if you stop the domain and restart it results in the following error below. Removing fragment.jar DOES NOT fix the problem either. I had to install a fresh copy of glassfish to get back a working server.

Adding host.war by itself was fine. It's after adding fragment.jar where the corruption happens. Before the restart the server seems to work ok (one.html and two.jsp are still served up) although I never got the fragment.jar (bar/three.html results in 404) to be recognized. Adding the fragment.jar to the WAR without the OSGi headers it works ok. Trying to use it as a OSGi fragment is where the problem occurs.

C:\dev\java\tools>glassfish-3.1.2-b20\glassfish3\bin\asadmin start-domain
Waiting for domain1 to start ..Error starting domain domain1.
The server exited prematurely with exit code 1.
Before it died, it produced the following output:

Launching GlassFish on Felix platform
ERROR: Bundle org.glassfish.main.javaee-api.javax.annotation [1] Error starting file:/C:/dev/java/tools/glassfish-3.1.2-
b20/glassfish3/glassfish/modules/endorsed/javax.annotation.jar (java.lang.NullPointerException)
ERROR: Bundle jaxb-api [2] Error starting file:/C:/dev/java/tools/glassfish-3.1.2-b20/glassfish3/glassfish/modules/endor
sed/jaxb-api-osgi.jar (java.lang.NullPointerException)
ERROR: Bundle org.glassfish.metro.webservices-api-osgi [3] Error starting file:/C:/dev/java/tools/glassfish-3.1.2-b20/gl
assfish3/glassfish/modules/endorsed/webservices-api-osgi.jar (java.lang.NullPointerException)
ERROR: Bundle org.glassfish.main.core.glassfish [101] Error starting file:/C:/dev/java/tools/glassfish-3.1.2-b20/glassfi
sh3/glassfish/modules/glassfish.jar (java.lang.NullPointerException)
ERROR: Bundle org.glassfish.hk2.osgi-adapter [203] Error starting file:/C:/dev/java/tools/glassfish-3.1.2-b20/glassfish3
/glassfish/modules/osgi-adapter.jar (java.lang.NullPointerException)
[WARN ][jrockit] PermSize=64m ignored: Not a valid option for JRockit
[WARN ][jrockit] MaxPermSize=192m ignored: Not a valid option for JRockit
[WARN ][jrockit] NewRatio=2 ignored: Not a valid option for JRockit
java.lang.NullPointerException
at org.apache.felix.framework.StatefulResolver$ResolverStateImpl.getCandidates(StatefulResolver.java:1263)
at org.apache.felix.framework.resolver.Candidates.populateFragmentOndemand(Candidates.java:347)
at org.apache.felix.framework.resolver.Candidates.populate(Candidates.java:148)
at org.apache.felix.framework.resolver.ResolverImpl.resolve(ResolverImpl.java:115)
at org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:168)
at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3819)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191)
at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295)
at java.lang.Thread.run(Thread.java:662)
java.lang.NullPointerException
at org.apache.felix.framework.StatefulResolver$ResolverStateImpl.getCandidates(StatefulResolver.java:1263)
at org.apache.felix.framework.resolver.Candidates.populateFragmentOndemand(Candidates.java:347)
at org.apache.felix.framework.resolver.Candidates.populate(Candidates.java:148)
at org.apache.felix.framework.resolver.ResolverImpl.resolve(ResolverImpl.java:115)
at org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:168)
at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3819)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191)
at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295)
at java.lang.Thread.run(Thread.java:662)
java.lang.NullPointerException
at org.apache.felix.framework.StatefulResolver$ResolverStateImpl.getCandidates(StatefulResolver.java:1263)
at org.apache.felix.framework.resolver.Candidates.populateFragmentOndemand(Candidates.java:347)
at org.apache.felix.framework.resolver.Candidates.populate(Candidates.java:148)
at org.apache.felix.framework.resolver.ResolverImpl.resolve(ResolverImpl.java:115)
at org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:168)
at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3819)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191)
at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295)
at java.lang.Thread.run(Thread.java:662)
java.lang.NullPointerException
at org.apache.felix.framework.StatefulResolver$ResolverStateImpl.getCandidates(StatefulResolver.java:1263)
at org.apache.felix.framework.resolver.Candidates.populateFragmentOndemand(Candidates.java:347)
at org.apache.felix.framework.resolver.Candidates.populate(Candidates.java:148)
at org.apache.felix.framework.resolver.ResolverImpl.resolve(ResolverImpl.java:115)
at org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:168)
at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3819)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191)
at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295)
at java.lang.Thread.run(Thread.java:662)
java.lang.NullPointerException
at org.apache.felix.framework.StatefulResolver$ResolverStateImpl.getCandidates(StatefulResolver.java:1263)
at org.apache.felix.framework.resolver.Candidates.populateFragmentOndemand(Candidates.java:347)
at org.apache.felix.framework.resolver.Candidates.populate(Candidates.java:148)
at org.apache.felix.framework.resolver.ResolverImpl.resolve(ResolverImpl.java:115)
at org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:168)
at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3819)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191)
at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295)
at java.lang.Thread.run(Thread.java:662)
Exception in thread "Main Thread" java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)
Caused by: org.glassfish.embeddable.GlassFishException: org.glassfish.embeddable.GlassFishException: No GlassFishRuntime
available
at com.sun.enterprise.glassfish.bootstrap.osgi.OSGiGlassFishRuntimeBuilder.build(OSGiGlassFishRuntimeBuilder.jav
a:164)
at org.glassfish.embeddable.GlassFishRuntime._bootstrap(GlassFishRuntime.java:157)
at org.glassfish.embeddable.GlassFishRuntime.bootstrap(GlassFishRuntime.java:110)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMain.java:112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:98)
at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:56)
Caused by: org.glassfish.embeddable.GlassFishException: No GlassFishRuntime available
at com.sun.enterprise.glassfish.bootstrap.osgi.OSGiGlassFishRuntimeBuilder.getGlassFishRuntime(OSGiGlassFishRunt
imeBuilder.java:202)
at com.sun.enterprise.glassfish.bootstrap.osgi.OSGiGlassFishRuntimeBuilder.build(OSGiGlassFishRuntimeBuilder.jav
a:162)
... 9 more
Error stopping framework: java.lang.NullPointerException
java.lang.NullPointerException
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher$1.run(GlassFishMain.java:203)

Command start-domain failed.



 Comments   
Comment by blackbeltdev [ 09/Feb/12 ]

Sorry I wasn't sure how to make sure you got my feedback so I cloned this issue. I was hoping to change the description...

I would say at a minimum this is a documentation issue because I was following the example from

http://glassfish.java.net/public/GF-OSGi-Features.pdf

which did NOT have the Bundle-Manifest header in the fragment example:

4.6 Static Resources and WAB

fragment.jar/
META-INF/
resources/
bar/
three.html
four.jsp
MANIFEST.MF
MANIFEST.MF contains:
Bundle-SymbolicName: fragment
Fragment-Host: host

However I would also like to point out that removing ALL the bundles from autodeploy folder and trying to restart glassfish it would NOT start.

I understand the root cause may lie with Felix but IMHO Oracle should devote resources to correct that issue ASAP. A single misconfigured Fragment should not kill the entire installation.

This looks really bad from a marketing aspect for glassfish which we are considering purchasing commerical support.

Comment by Sanjeeb Sahoo [ 09/Feb/12 ]

Hi,

Thanks for reporting the original issue. I have checked in a new version of the pdf document after correcting the bundle manifest.

The simple workaround to the problem is to remove the rogue fragment jar from the system and remove (rm -rf) osgi-cache located in glassfish/domains/domain1/osgi-cache. You don't have to reinstall glassfish. GlassFish will start fine after this.

Just in case you don't know, the primary committer in Apache Felix is an Oracle GlassFish Engineer called Richard S Hall. I have already filed the bug against Felix and it will get fixed. We will definitely integrate it as we always do.

Sahoo

Comment by blackbeltdev [ 09/Feb/12 ]

Awesome. Thanks Sahoo!





[GLASSFISH-18333] OSGi web fragment example corrupts glassfish installation Created: 07/Feb/12  Updated: 09/Feb/12  Resolved: 09/Feb/12

Status: Resolved
Project: glassfish
Component/s: admin, classloader, configuration, deployment, OSGi, OSGi-JavaEE, web_container
Affects Version/s: 3.1.2_b19, 3.1.2_b20
Fix Version/s: None

Type: Bug Priority: Blocker
Reporter: blackbeltdev Assignee: Sanjeeb Sahoo
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 64-bit

java version "1.6.0_29"
Java(TM) SE Runtime Environment (build 1.6.0_29-b11)
Oracle JRockit(R) (build R28.2.0-79-146777-1.6.0_29-20111005-1808-windows-x86_64, compiled mode)


Attachments: Zip Archive osgi-bug.zip     Zip Archive osgi-nofrag-works.zip     Zip Archive sayhello-works.zip    
Tags: fragment, osgi, wab

 Description   

I was trying to follow the tutorial from the section named "4.6 Static Resources and WAB" to deploy host.war and fragment.jar to Glassfish 3.1.2b19/20 from here:

http://glassfish.java.net/public/GF-OSGi-Features.pdf

I found out that I was able to corrupt the entire installation by simply adding fragment.jar to the autodeploy\bundle folder.

By tailing the logs you can see that it installed ok:

[#|2012-02-07T11:14:36.857-0600|INFO|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=17;_ThreadName=Thread-4;|Installed C:\dev\java\tools\glassfish-3.1.2-b20\glassfish3\glassfish\domains\domain1\autodeploy\bundles\fragment.jar|#]

But if you stop the domain and restart it results in the following error below. Removing fragment.jar DOES NOT fix the problem either. I had to install a fresh copy of glassfish to get back a working server.

Adding host.war by itself was fine. It's after adding fragment.jar where the corruption happens. Before the restart the server seems to work ok (one.html and two.jsp are still served up) although I never got the fragment.jar (bar/three.html results in 404) to be recognized. Adding the fragment.jar to the WAR without the OSGi headers it works ok. Trying to use it as a OSGi fragment is where the problem occurs.

C:\dev\java\tools>glassfish-3.1.2-b20\glassfish3\bin\asadmin start-domain
Waiting for domain1 to start ..Error starting domain domain1.
The server exited prematurely with exit code 1.
Before it died, it produced the following output:

Launching GlassFish on Felix platform
ERROR: Bundle org.glassfish.main.javaee-api.javax.annotation [1] Error starting file:/C:/dev/java/tools/glassfish-3.1.2-
b20/glassfish3/glassfish/modules/endorsed/javax.annotation.jar (java.lang.NullPointerException)
ERROR: Bundle jaxb-api [2] Error starting file:/C:/dev/java/tools/glassfish-3.1.2-b20/glassfish3/glassfish/modules/endor
sed/jaxb-api-osgi.jar (java.lang.NullPointerException)
ERROR: Bundle org.glassfish.metro.webservices-api-osgi [3] Error starting file:/C:/dev/java/tools/glassfish-3.1.2-b20/gl
assfish3/glassfish/modules/endorsed/webservices-api-osgi.jar (java.lang.NullPointerException)
ERROR: Bundle org.glassfish.main.core.glassfish [101] Error starting file:/C:/dev/java/tools/glassfish-3.1.2-b20/glassfi
sh3/glassfish/modules/glassfish.jar (java.lang.NullPointerException)
ERROR: Bundle org.glassfish.hk2.osgi-adapter [203] Error starting file:/C:/dev/java/tools/glassfish-3.1.2-b20/glassfish3
/glassfish/modules/osgi-adapter.jar (java.lang.NullPointerException)
[WARN ][jrockit] PermSize=64m ignored: Not a valid option for JRockit
[WARN ][jrockit] MaxPermSize=192m ignored: Not a valid option for JRockit
[WARN ][jrockit] NewRatio=2 ignored: Not a valid option for JRockit
java.lang.NullPointerException
at org.apache.felix.framework.StatefulResolver$ResolverStateImpl.getCandidates(StatefulResolver.java:1263)
at org.apache.felix.framework.resolver.Candidates.populateFragmentOndemand(Candidates.java:347)
at org.apache.felix.framework.resolver.Candidates.populate(Candidates.java:148)
at org.apache.felix.framework.resolver.ResolverImpl.resolve(ResolverImpl.java:115)
at org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:168)
at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3819)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191)
at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295)
at java.lang.Thread.run(Thread.java:662)
java.lang.NullPointerException
at org.apache.felix.framework.StatefulResolver$ResolverStateImpl.getCandidates(StatefulResolver.java:1263)
at org.apache.felix.framework.resolver.Candidates.populateFragmentOndemand(Candidates.java:347)
at org.apache.felix.framework.resolver.Candidates.populate(Candidates.java:148)
at org.apache.felix.framework.resolver.ResolverImpl.resolve(ResolverImpl.java:115)
at org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:168)
at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3819)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191)
at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295)
at java.lang.Thread.run(Thread.java:662)
java.lang.NullPointerException
at org.apache.felix.framework.StatefulResolver$ResolverStateImpl.getCandidates(StatefulResolver.java:1263)
at org.apache.felix.framework.resolver.Candidates.populateFragmentOndemand(Candidates.java:347)
at org.apache.felix.framework.resolver.Candidates.populate(Candidates.java:148)
at org.apache.felix.framework.resolver.ResolverImpl.resolve(ResolverImpl.java:115)
at org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:168)
at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3819)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191)
at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295)
at java.lang.Thread.run(Thread.java:662)
java.lang.NullPointerException
at org.apache.felix.framework.StatefulResolver$ResolverStateImpl.getCandidates(StatefulResolver.java:1263)
at org.apache.felix.framework.resolver.Candidates.populateFragmentOndemand(Candidates.java:347)
at org.apache.felix.framework.resolver.Candidates.populate(Candidates.java:148)
at org.apache.felix.framework.resolver.ResolverImpl.resolve(ResolverImpl.java:115)
at org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:168)
at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3819)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191)
at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295)
at java.lang.Thread.run(Thread.java:662)
java.lang.NullPointerException
at org.apache.felix.framework.StatefulResolver$ResolverStateImpl.getCandidates(StatefulResolver.java:1263)
at org.apache.felix.framework.resolver.Candidates.populateFragmentOndemand(Candidates.java:347)
at org.apache.felix.framework.resolver.Candidates.populate(Candidates.java:148)
at org.apache.felix.framework.resolver.ResolverImpl.resolve(ResolverImpl.java:115)
at org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:168)
at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3819)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191)
at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295)
at java.lang.Thread.run(Thread.java:662)
Exception in thread "Main Thread" java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)
Caused by: org.glassfish.embeddable.GlassFishException: org.glassfish.embeddable.GlassFishException: No GlassFishRuntime
available
at com.sun.enterprise.glassfish.bootstrap.osgi.OSGiGlassFishRuntimeBuilder.build(OSGiGlassFishRuntimeBuilder.jav
a:164)
at org.glassfish.embeddable.GlassFishRuntime._bootstrap(GlassFishRuntime.java:157)
at org.glassfish.embeddable.GlassFishRuntime.bootstrap(GlassFishRuntime.java:110)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMain.java:112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:98)
at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:56)
Caused by: org.glassfish.embeddable.GlassFishException: No GlassFishRuntime available
at com.sun.enterprise.glassfish.bootstrap.osgi.OSGiGlassFishRuntimeBuilder.getGlassFishRuntime(OSGiGlassFishRunt
imeBuilder.java:202)
at com.sun.enterprise.glassfish.bootstrap.osgi.OSGiGlassFishRuntimeBuilder.build(OSGiGlassFishRuntimeBuilder.jav
a:162)
... 9 more
Error stopping framework: java.lang.NullPointerException
java.lang.NullPointerException
at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher$1.run(GlassFishMain.java:203)

Command start-domain failed.



 Comments   
Comment by blackbeltdev [ 07/Feb/12 ]

Here are the sample projects using Gradle.

Comment by blackbeltdev [ 07/Feb/12 ]

Here's the non-OSGi fragment version which works. You have to build fragment project first and then host project.

Comment by blackbeltdev [ 07/Feb/12 ]

Same issue on 3.1.2-b21

Comment by blackbeltdev [ 08/Feb/12 ]

Here's a WAB that contains single servlet that is using multiple OSGi fragments (ResourceBundles for each language) that works fine.

I wonder if this is only an issue with pure static only fragments????

Comment by Sanjeeb Sahoo [ 09/Feb/12 ]

There is a problem with the fragment bundle. It does not have Bundle-ManifestVersion set to 2. Fragment bundles are an OSGi R4 concept, so they must be marked as an R4 bundle by having the following header in them:
Bundle-ManifestVersion: 2

When I update fragment.jar with the above header, everything works.

I understand the software should be more resilient, but the issue in the underlying platform. See [1].

[1] https://issues.apache.org/jira/browse/FELIX-3343

Comment by Sanjeeb Sahoo [ 09/Feb/12 ]

Closing as Invalid as opposed to "Won't fix"





[GLASSFISH-17531] Permanent timers cannot be persisted in OSGI environment Created: 30/Oct/11  Updated: 04/Oct/12

Status: Open
Project: glassfish
Component/s: OSGi-JavaEE
Affects Version/s: 3.1_b43
Fix Version/s: None

Type: Bug Priority: Major
Reporter: okna2000 Assignee: Sanjeeb Sahoo
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 3_1_2-exclude, osgi, timer

 Description   

as described in thread http://www.java.net/forum/topic/glassfish/glassfish/persistent-timers-problem:

I am using Glassfish 3.1, OSGI environment.

I created an EJB that creates persistent Timer objects (on demand) and adds them to TimerService. Timer runs until I restart the server. EJB is located in OSGI wab

After restart timerService.getTimers() return only the newly created timers and not the persisted.
Also, the timer doesn't run after restart.
I see that the timer appears in glassfish asadmin command: http://[server]:8080/ejb-timer-service-app/timer

code example:

@Resource
private TimerService timerService;

public void startTimer(String id){
timerService.createIntervalTimer(0, 6000, new TimerConfig(id, true/persist timers/));
}

@Timeout
public void sendAlerts(Timer timer){
logger.debug("Sending a timed alert");
}



 Comments   
Comment by julietzz [ 04/Oct/12 ]

Hello,

Any update or work around on this? I met the same problem with ejb osgi bundle, glassfish v3.1.2, and appreciate if there's any solution for the problem.

Thanks, Juliet





[GLASSFISH-17246] SLF4J API conflicts with org.glassfish.weld.WeldDeployer Created: 26/Aug/11  Updated: 30/Aug/11  Resolved: 30/Aug/11

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: 3.1.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: cinhtau Assignee: Sivakumar Thyagarajan
Resolution: Duplicate Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu Linux 10.04 LTS, Glassfish 3.1.1, SLF4J API 1.6.1..1.6.2, logback classic 0.9.29


Issue Links:
Duplicate
duplicates GLASSFISH-16964 [OSGi] Unable to use SLF4J 1.6.x Resolved
Tags: App, EJB, Hybrid, OSGi, cdi, logback, slf4j, weld

 Description   

Described in

http://old.nabble.com/HybridApplication-WeldBootstrap-Error-td32335499.html#a32340492

The deployment of my ejb bundle (hybrid application) fails, cause org.glassfish.weld.WeldDeployer throws an error.

server.log
2011-08-26T08:28:17.139+0200   WARNING
org.glassfish.osgijavaeebase                                     
Failed to deploy bundle de.sgbs.geo.service [386]
org.glassfish.osgijavaeebase.DeploymentException: Deployment of de.sgbs.geo.service [386] failed because of following reason: Failed while deploying bundle de.sgbs.geo.service [386] : java.lang.RuntimeException: Failed to deploy bundle [ de.sgbs.geo.service [386] ], root cause: Exception while loading the app
	at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:125)
	at org.glassfish.osgijavaeebase.OSGiContainer.deploy(OSGiContainer.java:154)
	at org.glassfish.osgijavaeebase.JavaEEExtender.deploy(JavaEEExtender.java:107)
	at org.glassfish.osgijavaeebase.JavaEEExtender.access$200(JavaEEExtender.java:61)
	at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:151)
	at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:148)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
	at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.RuntimeException: Failed to deploy bundle [ de.sgbs.geo.service [386] ], root cause: Exception while loading the app
	at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:196)
	at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:118)
	at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:121)
	... 10 more
Caused by: java.lang.NoSuchMethodError: org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V
	at org.slf4j.cal10n.LocLogger.info(LocLogger.java:122)
	at org.jboss.weld.bootstrap.WeldBootstrap.(WeldBootstrap.java:213)
	at org.glassfish.weld.WeldDeployer.load(WeldDeployer.java:345)
	at org.glassfish.weld.WeldDeployer.load(WeldDeployer.java:99)
	at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:186)
	at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:257)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:461)
	at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
	at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:183)
	... 12 more

I use SLF4J to route OSGi LogEntry to logback. This is not possible anymore, because after each restart of the application server the above error is thrown. Uninstalling slf4j api as bundle and it works again. Proposal: Separate slf4j with org.glassfish.weld, so other users can use slf4j.






Generated at Sat May 30 19:00:58 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.