[GLASSFISH-21149] A filter that changes the context class loader causes errors. Created: 30/Jul/14  Updated: 19/Sep/14  Resolved: 30/Jul/14

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

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


 Description   

The CDI integration layer is using the thread's context class loader to determine the application. If the user app changes the context class loader then we cannot find the correct application.



 Comments   
Comment by jjsnyder83 [ 30/Jul/14 ]

Committed revision 63553.





[GLASSFISH-20922] upgrading weld-osgi-bundle.jar into 2.2.1.Final Created: 10/Dec/13  Updated: 19/Sep/14  Resolved: 30/May/14

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

Type: Task Priority: Critical
Reporter: TangYong Assignee: jjsnyder83
Resolution: Fixed Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 4_0_1-approved

 Description   

upgrading weld-osgi-bundle.jar into 2.1.0.Final, in the version, there is the following big changes based on [1] and [2]

1. javax.inject has been removed from <_exportcontents> and javax.inject dependency has been removed

2. javax.enterprise.* has been removed from <_exportcontents> and javax.enterprise:cdi-api dependency has been removed

3. guava dependency has been removed

All is based on [3]and [4]

[1]: https://github.com/weld/core/blob/2.1/bundles/osgi/pom.xml
[2]: https://github.com/weld/core/commit/3e5cc452783161a9aae40160da1656216084bc33
[3]: https://issues.jboss.org/browse/WELD-1428
[4]: https://issues.jboss.org/browse/WELD-1477

Once upgrading 2.1.0.Final, these big changes will need GF distro to do the following:

1. javax.enterprise:cdi-api will be put into modules
2. whether current guava module in gf will meet the demand from weld-osgi-bundle. This needs to be confirm.



 Comments   
Comment by TangYong [ 10/Dec/13 ]

3. also confirm whether some modules which only depend on cdi api originally exported by weld-osgi-bundle, needs to be
switched into depending on javax.enterprise:cdi-api?

Comment by mauritzlovgren [ 01/Apr/14 ]

Might be important to inform current 4.0.0 users of the serious memory leak in the Weld version that is bundled with 4.0.0 release (Weld 2.0). Weld has released a fix for part of this memory leak that was causing big trouble in our production environment: http://weld.cdi-spec.org/news/2014/01/14/weld-212-final/. I assume that GF 4.0.1 will have a newer version of Weld, at least 2.0.5.Final or newer?).

Comment by elio.alves [ 14/Apr/14 ]

I fix this bug and update the weld version toweld-2.1.2.Final but I dont know how to commit.

Somebody can help-me?

Below my changes

update of lib weld-osgi-api to weld-2.1.2.Final because the atual version have a bug that mixing the sessions
update on BootstrapConfigurationImpl and ACLSingletonProvider to works with weld-2.1.2.Final. I implemented 4 methods that reuse the same old methods
I put two others bundles because the weld require it
I created another packager... but i dont know if are in the correct form, but, works fine

Comment by elio.alves [ 14/Apr/14 ]

How I can commit my changes?
This is my first fix in the java.net/jira

Comment by jjsnyder83 [ 15/Apr/14 ]

If you send me the changes I will get them committed in the next few days. There are a couple other steps that have to be done too before we can change the version.

Comment by elio.alves [ 28/May/14 ]

Hi jjsnyder83.

How I can send to you?

Comment by jjsnyder83 [ 28/May/14 ]

I am in the middle of updating GlassFish to CDI 1.2 and Weld 2.2.1.Final. I have a few tck failures to track down and then I will check it all in. Hopefully in a few days.

Comment by jjsnyder83 [ 30/May/14 ]

Committed revision 63317.

There are still a couple of tck failures. Jersey is causing a bunch and the Jersey team is supposed to update the version used in GlassFish today or tomorrow. Also there are 2 ejb test failures that should be fixed soon.





[GLASSFISH-20597] UnsatisfiedDependencyException is thrown by JAX-RS, Bean Validation and CDI integration Created: 31/May/13  Updated: 19/Sep/14  Resolved: 11/Jun/13

Status: Resolved
Project: glassfish
Component/s: bean-validator, cdi, jax-rs
Affects Version/s: 4.0_b89_RC5
Fix Version/s: 4.1

Type: Bug Priority: Major
Reporter: HASUNUMA Kenji Assignee: Michal Gajdos
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 and JDK7 update 21 (both x86 and x86-64)


Issue Links:
Duplicate
duplicates GLASSFISH-20255 @Inject Strange Errors Closed
Related
is related to JERSEY-1908 UnsatisfiedDependencyException is th... Closed
Tags: beanvalidation, cdi, jax-rs

 Description   

It is problem that a JAX-RS application (exactly a resource class) throws org.glassfish.hk2.api.UnsatisfiedDependencyException when I send GET request to it. The application uses both Bean Validation (@NotNull and @Min) and CDI (@Inject) into same resource class and it is neither Managed Bean nor EJB (Session Bean). If it uses either of them (for example, it uses without Bean Validation), it runs well and send response as status 200.

As a trial, I rewrite the application using not @Inject but @EJB (the resource class becomes Stateless Bean) and then it runs as expected.



 Comments   
Comment by Marek Potociar [ 04/Jun/13 ]

Please provide a reproducible test case. Marking as incomplete, targeting for 4.0.1. Will be closed if a reproducible test case is not provided.

Comment by HASUNUMA Kenji [ 04/Jun/13 ]

I seem to have no privilege with attached files, so I write the parts of application that throws UnsatisfiedDependencyException as following;

TweetResource.java (Resource class)
package jp.co.ines.sagittarius.api.twitter;

import java.util.List;

import javax.ejb.EJB;
import javax.ejb.Stateless;
import javax.inject.Inject;
import javax.validation.constraints.Min;
import javax.validation.constraints.NotNull;
import javax.ws.rs.DefaultValue;
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.Produces;
import javax.ws.rs.QueryParam;

import twitter4j.TwitterException;

@Path("/twitter")
@Stateless
public class TwitterResource {
  @Inject
  private TwitterSearch twitterSearch;
  
  @GET
  @Path("/search")
  @Produces({"application/xml", "application/json"})
  public List<Tweet> search(@QueryParam("q") @NotNull String queryString,
      @DefaultValue("100") @QueryParam("count") @Min(1) int count) 
      throws TwitterException {
    return twitterSearch.search(queryString, count);
  }
  
  @GET
  @Path("/peek")
  @Produces({"application/xml", "application/json"})
  public List<Tweet> peek(@QueryParam("q") String queryString, 
      @QueryParam("count") @Min(1) int count) throws TwitterException {
    return twitterSearch.peek(queryString, count);
  }
}
TweetSearch.java (Injected EJB)
package jp.co.ines.sagittarius.api.twitter;

import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.TimeUnit;

import javax.ejb.Stateless;
import javax.ws.rs.InternalServerErrorException;
import javax.ws.rs.ServiceUnavailableException;

import twitter4j.Query;
import twitter4j.QueryResult;
import twitter4j.RateLimitStatus;
import twitter4j.Status;
import twitter4j.Twitter;
import twitter4j.TwitterException;
import twitter4j.TwitterFactory;

@Stateless
public class TwitterSearch {
  private static final int API_RATE_LIMIT = 180;
  private static final int SEARCH_RATE_LIMIT = 60;
  private static final int PEEK_RATE_LIMIT = 30;
  private static final int TWEETS_PER_PAGE = 100;
	
  public List<Tweet> search(String queryString, int count) 
      throws TwitterException {
    Twitter twitter = new TwitterFactory().getInstance();
    
    RateLimitStatus rateLimitStatus = 
      twitter.search(new Query("from:home")).getRateLimitStatus();
    if (getPages(count) > getRemaining(rateLimitStatus, SEARCH_RATE_LIMIT)) {
      throw new ServiceUnavailableException(
        (long) rateLimitStatus.getSecondsUntilReset());
    }
    
    Query query = new Query(queryString);
    query.setCount(TWEETS_PER_PAGE);
    
    List<Tweet> results = new ArrayList<>();
    for (int page = 0; page < getPages(count); page++) {
      QueryResult result = twitter.search(query);
      if (result.getTweets().isEmpty()) {
        break;
      }
      
      for (Status status : result.getTweets()) {
        Tweet tweet = new Tweet();
        tweet.setId(status.getId());
        tweet.setCreateAt(status.getCreatedAt());
        tweet.setFromUser(status.getUser().getScreenName());
        tweet.setFromUserName(status.getUser().getName());
        tweet.setProfileImageUrl(status.getUser().getProfileImageURLHttps());
        tweet.setVerified(status.getUser().isVerified());
        tweet.setText(status.getText());
        results.add(tweet);
      }
      query.setMaxId(result.getTweets().get(0).getId() - 1L);
    }
    return results;
  }

  public List<Tweet> peek(String queryString, int count) throws TwitterException {
    Twitter twitter = new TwitterFactory().getInstance();
    
    RateLimitStatus rateLimitStatus = twitter.search(
      new Query("from:home")).getRateLimitStatus();
    if (getPages(count) > getRemaining(rateLimitStatus, WATCH_RATE_LIMIT)) {
      throw new ServiceUnavailableException(
        (long) rateLimitStatus.getSecondsUntilReset());
    }
    
    Query query = new Query(queryString);
    query.setCount(TWEETS_PER_PAGE);
    
    List<Tweet> results = new ArrayList<>();
    for (int page = 0; page < getPages(count); page++) {
      QueryResult result = twitter.search(query);
      if (result.getTweets().isEmpty()) {
        break;
      }
      for (Status status : result.getTweets()) {
        Tweet tweet = new Tweet();
        tweet.setId(status.getId());
        tweet.setCreateAt(status.getCreatedAt());
        tweet.setFromUser(status.getUser().getScreenName());
        tweet.setFromUserName(status.getUser().getName());
        tweet.setProfileImageUrl(status.getUser().getProfileImageURLHttps());
        tweet.setVerified(status.getUser().isVerified());
        tweet.setText(status.getText());
        results.add(tweet);
      }
      try {
        int until = result.getRateLimitStatus().getSecondsUntilReset();
        int wait = until / getRemaining(
          result.getRateLimitStatus(), PEEK_RATE_LIMIT);
          TimeUnit.SECONDS.sleep(wait);
      } catch (InterruptedException e) {
        e.printStackTrace();
        throw new InternalServerErrorException(e);
      }
      query.setMaxId(result.getTweets().get(0).getId() - 1L);
    }
    return results;
  }
  
  private int getRemaining(RateLimitStatus rateLimitStatus, int rateLimit) {
    return rateLimitStatus.getRemaining() - (API_RATE_LIMIT - rateLimit);
  }
	
  private int getPages(int count) {
    return (count + TWEETS_PER_PAGE - 1) / TWEETS_PER_PAGE;
  }
}
Tweet.java (in part of)
package jp.co.ines.sagittarius.api.twitter;

import static javax.xml.bind.annotation.XmlAccessType.FIELD;

import java.io.Serializable;
import java.util.Date;

import javax.xml.bind.annotation.XmlAccessorType;
import javax.xml.bind.annotation.XmlElement;
import javax.xml.bind.annotation.XmlRootElement;

@XmlRootElement
@XmlAccessorType(FIELD)
public class Tweet implements Serializable {
  private static final long serialVersionUID = 3677514835637906987L;

  @XmlElement private long id;
  @XmlElement private Date createAt;
  @XmlElement private String fromUser;
  @XmlElement private String fromUserName;
  @XmlElement private String profileImageUrl;
  @XmlElement private boolean verified;
  @XmlElement private String text;

  // omit following getters/setters because of verbose description
}
WEB-INF/beans.xml
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://java.sun.com/xml/ns/javaee"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
       http://java.sun.com/xml/ns/javaee/beans_1_0.xsd">
</beans>

UnsatisfiedDependencyException is thrown directly following TwitterResource#search method. But I think it is also happen in TwitterSearch#peek method.

Remarks:

  • This application uses Twitter4J 3.0.3 (http://twitter4j.org/).
  • If I remove "@NotNull" and "@Min" from above TwitterResource, this runs well.
  • If I also replace "@Inject" to "@EJB" from above one, this runs well.


If possible, please grant attached files role to me because that I'll add reproducible test cases to future issues. I sent "Oracle Contributor Agreement" and wait it's acceptance.

Comment by Michal Gajdos [ 10/Jun/13 ]

Hi,

can you paste the whole stacktrace of the exception? Are you running this example on GlassFish or on something else?

Thanks.

Comment by HASUNUMA Kenji [ 10/Jun/13 ]

I run the example only on GlassFish 4.0 build 89.

The whole stacktrace is following;

org.glassfish.hk2.api.UnsatisfiedDependencyException: There was no object available for injection at Injectee(requiredType=TwitterSearch,parent=TwitterResource,qualifiers={}),position=-1,optional=false,self=false,unqualified=null,1920339034)
at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:74)
at org.jvnet.hk2.internal.Utilities.justInject(Utilities.java:771)
at org.jvnet.hk2.internal.ServiceLocatorImpl.inject(ServiceLocatorImpl.java:790)
at org.glassfish.jersey.gf.cdi.CdiComponentProvider$1.inject(CdiComponentProvider.java:316)
at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:158)
at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:69)
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:716)
at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:738)
at org.glassfish.jersey.gf.cdi.CdiComponentProvider$CdiFactory$1.getInstance(CdiComponentProvider.java:174)
at org.glassfish.jersey.gf.cdi.CdiComponentProvider$CdiFactory.provide(CdiComponentProvider.java:143)
at org.jvnet.hk2.internal.FactoryCreator.create(FactoryCreator.java:96)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:448)
at org.jvnet.hk2.internal.PerLookupContext.findOrCreate(PerLookupContext.java:69)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2204)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:579)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:566)
at org.glassfish.jersey.internal.inject.Injections.getOrCreate(Injections.java:172)
at org.glassfish.jersey.server.model.MethodHandler$ClassBasedMethodHandler.getInstance(MethodHandler.java:185)
at org.glassfish.jersey.server.internal.routing.PushMethodHandlerRouter.apply(PushMethodHandlerRouter.java:105)
at org.glassfish.jersey.server.internal.routing.RoutingStage._apply(RoutingStage.java:118)
at org.glassfish.jersey.server.internal.routing.RoutingStage._apply(RoutingStage.java:121)
at org.glassfish.jersey.server.internal.routing.RoutingStage._apply(RoutingStage.java:121)
at org.glassfish.jersey.server.internal.routing.RoutingStage._apply(RoutingStage.java:121)
at org.glassfish.jersey.server.internal.routing.RoutingStage._apply(RoutingStage.java:121)
at org.glassfish.jersey.server.internal.routing.RoutingStage.apply(RoutingStage.java:102)
at org.glassfish.jersey.server.internal.routing.RoutingStage.apply(RoutingStage.java:62)
at org.glassfish.jersey.process.internal.Stages.process(Stages.java:197)
at org.glassfish.jersey.server.ServerRuntime$1.run(ServerRuntime.java:215)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
at org.glassfish.jersey.internal.Errors.process(Errors.java:267)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:198)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:946)
at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:323)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:372)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:335)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:218)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:318)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:99)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:357)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:260)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:188)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:722)

Comment by Michal Gajdos [ 11/Jun/13 ]

Thanks for the stacktrace.

This issue is a duplicate of GLASSFISH-20255. The fix will be present in GF 4.0.1 and after the official release of GF 4.0 we will provide an IPS update package with Jersey where this issue is fixed. (I'll let you know when the package is available)

In the meantime you can download the jersey-gf-cdi from maven central ([1]), replace this module in glassfish4/glassfish/modules and delete the osgi cache glassfish4/glassfish/domains/domain1/osgi-cache/felix. This should fix the issue.

[1] http://repo1.maven.org/maven2/org/glassfish/jersey/containers/glassfish/jersey-gf-cdi/2.0/jersey-gf-cdi-2.0.jar





[GLASSFISH-20540] PSR:PERF Implicit CDI causing 30% performance regression Created: 16/May/13  Updated: 11/May/15  Resolved: 11/May/15

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

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

Tags: 4_0_1-reviewed, PSRBUG

 Description   

Micro benchmarks on EJB local session beans have regressed by 30% in current build. This is because of implicit CDI; if I set cdi-enable-implicit=false, performance reverts to previous levels.

I suspect this is a new weld integration to fix for https://java.net/jira/browse/GLASSFISH-20474 – and the memory leak is fixed, but we are left with the new performance regression.

The WeldListnener is consuming about 30% of total CPU now, particularly in the WeldListener.requestDestroy() method.



 Comments   
Comment by jjsnyder83 [ 22/May/13 ]

I'm not sure there's much we can do about this. As you stated, when you disable implicit cdi you get the same results as before. With implicit cdi enabled cdi is getting involved with the ejbs and so additional processing is happening. If cdi is not required then it should be turned off for maximum performance.

Comment by Scott Oaks [ 22/May/13 ]

I don't think "work as intended" is an accurate description – I don't think the intention of enabling CDI by default is to introduce a 30% performance regression in EJB operations.

We need to look into and optimize the Weld implementation here. If we conclude that it cannot be improved on, then we can figure out next steps. But I suspect, given the size of the penalty, that there is some optimizing we can do. I'll get PSR staff to do some initial analysis (but also, can we check with the Weld implementors and see if they are aware of this, as they were already aware of the memory leak)?

Comment by jjsnyder83 [ 22/May/13 ]

Enabling CDI causes CDI to get involved in all EJB requests so if there's a lot of EJB "action" happening then there's going to be a performance hit when CDI is involved. I agree 30% seems drastic!

It's entirely possible that Weld can improve the implementation and I'll be glad to open a Weld Jira. It would be very helpful if I could provide some more information as well as an application that when run emphasizes the performance hit...Can the PSR staff provide that info?

(btw, The weld guys were not aware of the memory leak until we pointed it out )

Comment by phil.zampino [ 24/Jun/13 ]

After a brief exchange with the Weld lead, I've filed https://issues.jboss.org/browse/WELD-1443

Comment by phil.zampino [ 26/Jun/13 ]

The associated Weld issue is scheduled to be included in Weld 2.0.3.Final

Comment by jjsnyder83 [ 11/May/15 ]

Should be fixed by upgrade to Weld 2.2.10.SP1 which happened a few weeks ago.





[GLASSFISH-20483] Enable and disable implicit scanning per JAR. Created: 07/May/13  Updated: 17/Dec/15  Resolved: 12/Jun/13

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

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


 Description   

beans.xml cannot be added to a third-party JAR. Disabling implicit CDI is one option but but it works at the application level.

This will not work when different third-party JARs make different assumptions about implicit beans. So it would be helpful if GlassFish (or Weld) offered a way to enable or disable implicit scanning per JAR.



 Comments   
Comment by jjsnyder83 [ 07/May/13 ]

According to 12.1 of CDI spec:
"For compatibility with Contexts and Dependency 1.0, products must contain an option to cause an archive to be ignored by the container when no beans.xml is present."

We are probably a little light in our implementation of this as we only allow entire apps to be enabled/disabled for implicit scanning.

Comment by aaronjwhiteside [ 28/May/13 ]

Related to GLASSFISH-20579. It would be good if this was part of the final 4.0.0 release. Perhaps something in glassfish-web.xml?

Comment by aaronjwhiteside [ 28/May/13 ]

http://docs.jboss.org/weld/reference/latest/en-US/html/configure.html

This doesn't work as far as I can tell.

Maybe fixing the WELD integration so that this works is the solution?

Comment by aaronjwhiteside [ 29/May/13 ]

I can add a beans.xml as per the CDI 1.1 spec, but that does not appear to work either.

CDI 1.1 Spec, Section 12.1
bean-discovery-mode="none" should disable an archives contents from being considered by CDI.

Comment by phil.zampino [ 10/Jun/13 ]

The cited beans.xml addition should work. If it is being applied correctly, and Glassfish is not honoring it, then that's a bug. Can you provide an application to reproduce this behavior?

Additionally, there is a new deployment property that will disable support for implicit bean archives at the application level. (asadmin deploy --property implicitCdiEnabled=false <archive file>)

Comment by everett_toews [ 07/Oct/14 ]

How exactly was this resolved?

bean-discovery-mode="none" does work for me but this issue is for disabling implicit scanning per JAR.

To disable scanning per JAR I tried the following beans.xml and it didn't work for me. I continue to get WELD errors.

<beans xmlns="http://java.sun.com/xml/ns/javaee" 
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
       xmlns:weld="http://jboss.org/schema/weld/beans" 
       xsi:schemaLocation="
          http://java.sun.com/xml/ns/javaee http://docs.jboss.org/cdi/beans_1_0.xsd
          http://jboss.org/schema/weld/beans http://jboss.org/schema/weld/beans_1_1.xsd">
    <weld:scan>
        <weld:exclude name="org.jclouds.**" />
    </weld:scan>
</beans>

Should this beans.xml work with Glassfish 4.1?

Can someone provide an example of a beans.xml file that excludes per JAR that does work?

Thanks.

Comment by everett_toews [ 07/Oct/14 ]

Just to be clear, I put that beans.xml file in the web app WEB-INF dir.

Comment by reipince [ 17/Dec/15 ]

This is not fixed.

I have jars that contain unimplemented interfaces, and therefore when they're scanned for CDI, they cause an error and I can't deploy my app.

I tried explicitly using an exclude rule in my beans.xml but it seems to take no effect.

My options are:

  • disable implicit cdi at the application level
  • disable cdi scanning at the beans.xml level (using "none" as the bean-discovery-mode).

Both of these options are bad since they require me to explicitly annotate everything that's being injected right now, which is quite a lot of stuff...

Comment by jjsnyder83 [ 17/Dec/15 ]

You have the following choices:
1) Disable implicit CDI for all apps. Use this command:
asadmin set configs.config.server-config.cdi-service.enable-implicit-cdi=false

2) Disable CDI for each jar you do not want to participate in CDI. To do this you must add a beans.xml to each individual jar with the following content:

<beans
xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd"
bean-discovery-mode="none">
</beans>

Note that for option 2 you must do this for each individual jar. The beans.xml in WEB-INF only applies to the classes in WEB-INF/classes.





[GLASSFISH-20450] Weld combination of API/implementation in single bundle slows down server startup Created: 01/May/13  Updated: 19/Sep/14  Resolved: 16/Apr/14

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

Type: Bug Priority: Major
Reporter: Tom Mueller Assignee: phil.zampino
Resolution: Duplicate Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: devx_web

 Description   

Currently, the weld-osgi-bundle.jar file contains the javax.enterprise.* (context, inject, event, etc.) classes (the API consisting of 108 classes) and 2716 implementation classes (org.jboss.weld, etc.).

Experiments have shown that if this bundle is split into two bundles, e.g., weld-osgi-api.jar and weld-osgi-impl.jar, then a 3% improvement can be achieved in the devx_web performance benchmark. After server startup, the weld-osgi-impl.jar stays in the installed state. It is resolved during application deployment.

This issue is for making this split.



 Comments   
Comment by Tom Mueller [ 01/May/13 ]

Here is an analysis of how the bundle status changes given this change:

After a server start (with no application), the following modules are no longer resolved after the split (they are in the installed state):

Deployment Related JavaEE Full Profile Classes
JavaServer Pages(TM) Standard Tag Library API
Mojarra JSF Implementation 2.2.0
Weld connector for glassfish
Weld integration for glassfish
org.glassfish.main.web.weld-integration-fragment

The state of all bundles after the deploy of an application is the same (except there is the new added bundle which is resolved).

Comment by jjsnyder83 [ 01/May/13 ]

The packages to move into an weld-osgi-api.jar include:
javax.enterprise.*
javax.decorator

Comment by Tom Mueller [ 02/May/13 ]

It would be nice to get this into 4.0, if possible. Please evaluate.

Comment by tlcksnyder [ 02/May/13 ]

Defer to 4.0.1.

Comment by Sanjeeb Sahoo [ 03/May/13 ]

I think we have a bad dependency issue here. We should not separate the api from implementation bundle.

Comment by mtaube [ 06/May/13 ]

weld-integration-fragment attaches to the weld osgi-bundle, and imports from the weld-integration bundle. This seems to be what is causing the transitive resolution of ejb-container.

Comment by Sanjeeb Sahoo [ 07/May/13 ]

Was weld-osgi bundle getting resolved in 3.1.2 as well? Or is this bad dependency a regression in 4.0?

Comment by Tom Mueller [ 07/May/13 ]

Here are the states of the Weld related bundles after starting 3.1.2:

Weld OSGi Bundle | 3.1.2 | Resolved
Weld integration for glassfish | 3.1.2 | Active
org.glassfish.main.web.weld-integration-fragment | 3.1.2 | Resolved

The problem in 4.0 is not so much that these bundles are getting resolved, but that in 4.0, the resolution of weld-osgi-bundle.jar causes ejb-container to be resolved as well where it didn't in 3.1.2. See issue GLASSFISH-20409.

Comment by Sanjeeb Sahoo [ 07/May/13 ]

My point is we should not separate APIs from implementations. They are against our preferred packaging approach as Bill described in maven/osgi/javaee packaging document. The APIs should only be needed if the corresponding implementation is also needed. It seems to me that some bundles are incorrectly packaged leading these kind of issues.

Comment by TangYong [ 17/Nov/13 ]

Just now, we(I and Jeremy) have done a hard test for the issue as following:

We are doing GlassFish on-demand starting experiments and we have decreased modules into mini-modules for meeting GlassFish Domain normal Starting.

In these mini-modules, some modules as API are necessary and this is reasonable. However,weld-osgi-bundle.jar can not be removed. We know that some modules depend on CDI and only depend on CDI API rather than Impl. We wish that API from weld-osgi-bundle.jar can be separated in order that in on-demand starting env, we can only preserve API and remove impl. Thus, this will improve GF Starting performance.

So, from this point, I agree with separating APIs from implementations.

Comment by TangYong [ 19/Nov/13 ]

Pl. allowing me explain the issue in detailed:

javax.transaction-api.jar imports javax.enterprise.context package, so it depends on cdi api 1.1. On minimizing GlassFish domain starting, javax.transaction-api.jar is necessary.

Well, because cdi api 1.1 is wrapped into weld-osgi-bundle.jar, we must include weld-osgi-bundle.jar even though it also wraps
cdi 1.1 implementation while minimizing GlassFish domain starting. So, from this point, we should separate cdi api from implementations.

On the other hand, I looked into the newest wildfly-8.0.0.Beta1, on its modules splitting, about CDI, it has the following modules,

1) cdi-api-1.1.jar

Its aim is only for cdi api 1.1

2) weld-api-2.1.CR1.jar

Its aim is for weld api, this is related to implementation.

3) weld-core-impl-2.1.0.CR1.jar

Its aim is for weld implementation, this is related to implementation.

4) weld-spi-2.1.CR1.jar

Its aim is for weld spi implementation, this is related to implementation.

Based on the above analyse, I think that current weld-osgi-bundle.jar is not good for modulation principle.

Best Regards!
Tang

Comment by TangYong [ 06/Dec/13 ]

in current GF modules, there are two modules which all exports 'javax.inject'.

1) weld-osgi-bundle.jar
2) javax.inject.jar

seperating Weld API from implementation is a solution for the issue.

Comment by TangYong [ 10/Dec/13 ]

The issues related to this jira will be resolved by GLASSFISH-20922.

Pl. confirming and closing this jira.

Comment by jjsnyder83 [ 16/Apr/14 ]

Duplicate of https://java.net/jira/browse/GLASSFISH-20922





[GLASSFISH-20422] multiple extensions in same bda Created: 26/Apr/13  Updated: 11/May/15  Resolved: 11/May/15

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

Type: Bug Priority: Minor
Reporter: jjsnyder83 Assignee: phil.zampino
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 4_0_1-approved

 Description   

So in my debugging of the Producer Bean issue I noticed that in GF we have a jar that contains multiple extensions and no beans.xml. So I have the following questions:
1) Should there be 1 bda for each extension or can multiple extensions go into the same bda?
Multiple extensions can go into the same BDA as long as accessibility rules are fulfilled. Definitely no need to create separate bda per extension.
2) Should the extension class itself be placed into the bda as a bean class?
If they are packaged in the same archive then yes they should end up in the same BDA. However, if you create multiple BDAs and reflect accessibility rules within them in the BDA graph it should again not make a difference.

Also in DeploymentImpl.getBeanDeploymentArchive check the extension bdas too.



 Comments   
Comment by jjsnyder83 [ 11/May/15 ]

This works just fine the way the code is written.





[GLASSFISH-20414] automate jms resource creation for weld glassfish tck runner Created: 25/Apr/13  Updated: 26/Apr/13  Resolved: 26/Apr/13

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

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


 Description   

See
https://github.com/weld/weld-glassfish-tck-runner/blob/master/src/test/java/org/jboss/weld/tck/glassfish/GlassFishResourceManager.java#L36

Wouldn't it be better to support this directly in the Managed/Remote containers in the same way it's done for Embedded, by exposing a configuration option in ContainerConfiguration. Then any user can install a global resources.xml file during the lifetime of the test execution. Installed in start(), removed in stop() ?

glassfish embedded configuration:
https://github.com/arquillian/arquillian-container-glassfish/blob/master/glassfish-embedded-3.1/src/main/java/org/jboss/arquillian/container/glassfish/embedded_3_1/GlassFishConfiguration.java#L156

glassfish embedded impl:
https://github.com/arquillian/arquillian-container-glassfish/blob/master/glassfish-embedded-3.1/src/main/java/org/jboss/arquillian/container/glassfish/embedded_3_1/GlassFishContainer.java#L186

glassfish-resources.xml example: https://github.com/ahhughes/glassfish3x.resources.xml.example/blob/master/glassfish3x-resources-xml-example-ear/src/main/application/META-INF/glassfish-resources.xml



 Comments   
Comment by jjsnyder83 [ 26/Apr/13 ]

https://java.net/jira/browse/GLASSFISH-20413





[GLASSFISH-20411] Add readme to https://github.com/weld/weld-glassfish-tck-runner Created: 25/Apr/13  Updated: 19/Sep/14  Resolved: 22/May/13

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

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


 Description   

Add a readme to the weld glassfish tck runner describing the setup required to run the tck. It should include:

  • defining jms resource
  • setting 1 environment variable
  • including 1 application library


 Comments   
Comment by jjsnyder83 [ 25/Apr/13 ]

Must also set enable implicit cdi to tru

Add following under <configs> -><config name="server-config">
<cdi-service enable-implicit-cdi="true"></cdi-service>

Add following under <admin-service system-jmx-connector-name="system" type="das-and-server">

<das-config deploy-xml-validation="none"></das-config>

under the <java-config ...> element add these:
<jvm-options>-DcdiTckExcludeDummy=true</jvm-options>
<jvm-options>-ea:org.jboss.cdi.tck...</jvm-options>

Here's the asadmin commands
asadmin create-jms-resource --restype javax.jms.Queue --property Name=queue_test queue_test
asadmin create-jms-resource --restype javax.jms.Topic --property Name=topic_test topic_test





[GLASSFISH-20323] FindBugs fixes Created: 16/Apr/13  Updated: 19/Sep/14  Resolved: 12/Jun/13

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: 4.0_b83
Fix Version/s: 4.1

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


 Comments   
Comment by jjsnyder83 [ 18/Apr/13 ]
  • What is the impact on the customer of the bug?
    None

How likely is it that a customer will see the bug and how serious is the bug?
Is it a regression? Does it meet other bug fix criteria (security, performance, etc.)?
What CTS failures are caused by this bug?
findBugs fix

  • What is the cost/risk of fixing the bug?
    None

How risky is the fix? How much work is the fix? Is the fix complicated?
very minor

  • Is there an impact on documentation or message strings?
    No
  • Which tests should QA (re)run to verify the fix did not destabilize GlassFish?
    quicklook
  • Which is the targeted build of 4.0 for this fix?
    4.0_b85
  • If this an integration of a new version of a component from another project,
    what are the changes that are being brought in? This might be list of
    Jira issues from that project or a list of revision messages.
    N/A




[GLASSFISH-20141] Redeployment raises ComputationException - IllegalStateException: WELD-001328 Unable to identify the correct BeanManager. The calling class org.jboss.weld.servlet.WeldListener is not placed in bean archive Created: 03/Apr/13  Updated: 19/Sep/14  Resolved: 22/May/13

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

Type: Bug Priority: Minor
Reporter: myfear Assignee: arjavdesai
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Win7
JDK 1.7_15 x64
NetBeans 7.3


Tags: fishcat

 Description   

Hi,

I have a simple Java EE 7 app which deploys perfectly fine (at least for the first time.) Every re-deployment attempt from Netbeans leads to the following exception. I have seen this a couple of times before with different applications on GF 4 already ...

The source is here: https://www.dropbox.com/s/n8uhy2uka8p5vo4/websockets-demo.zip

INFO: JMS013: Assuming destination type javax.jms.Queue for MDB MessageReceiverSync from administered object jms/myQueue
WARNING: Could not load service class com.ibm.jbatch.container.services.BatchCDIInjectionExtension
INFO: Registering WebSocket filter for url pattern /*
INFO: Mojarra 2.2.0-m11 (-SNAPSHOT 20130311-2013 https://svn.java.net/svn/mojarra~svn/tags/2.2.0-m11@11723) für Kontext '/websockets-demo' wird initialisiert.
SEVERE: Startup of context /websockets-demo failed due to previous errors
SEVERE: Exception during cleanup after start failed
org.apache.catalina.LifecycleException: Manager has not yet been started
at org.apache.catalina.session.StandardManager.stop(StandardManager.java:934)
at org.apache.catalina.core.StandardContext.stop(StandardContext.java:6099)
at com.sun.enterprise.web.WebModule.stop(WebModule.java:720)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5916)
at com.sun.enterprise.web.WebModule.start(WebModule.java:691)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:1041)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:1024)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:747)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2291)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1937)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:139)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:497)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1761)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:534)
at com.sun.enterprise.v3.admin.AdminAdapter.onMissingResource(AdminAdapter.java:224)
at org.glassfish.grizzly.http.server.StaticHttpHandler.service(StaticHttpHandler.java:297)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:722)

SEVERE: ContainerBase.addChild: start:
org.apache.catalina.LifecycleException: com.google.common.collect.ComputationException: org.jboss.weld.exceptions.IllegalStateException: WELD-001328 Unable to identify the correct BeanManager. The calling class org.jboss.weld.servlet.WeldListener is not placed in bean archive
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5920)
at com.sun.enterprise.web.WebModule.start(WebModule.java:691)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:1041)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:1024)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:747)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2291)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1937)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:139)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:497)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1761)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:534)
at com.sun.enterprise.v3.admin.AdminAdapter.onMissingResource(AdminAdapter.java:224)
at org.glassfish.grizzly.http.server.StaticHttpHandler.service(StaticHttpHandler.java:297)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:722)
Caused by: com.google.common.collect.ComputationException: org.jboss.weld.exceptions.IllegalStateException: WELD-001328 Unable to identify the correct BeanManager. The calling class org.jboss.weld.servlet.WeldListener is not placed in bean archive
at com.google.common.collect.ComputingConcurrentHashMap$ComputingMapAdapter.get(ComputingConcurrentHashMap.java:400)
at org.jboss.weld.Weld.getBeanManager(Weld.java:115)
at org.jboss.weld.Weld.getBeanManager(Weld.java:46)
at org.jboss.weld.servlet.WeldListener.contextInitialized(WeldListener.java:119)
at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:5362)
at com.sun.enterprise.web.WebModule.contextListenerStart(WebModule.java:743)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:5898)
... 44 more
Caused by: org.jboss.weld.exceptions.IllegalStateException: WELD-001328 Unable to identify the correct BeanManager. The calling class org.jboss.weld.servlet.WeldListener is not placed in bean archive
at org.jboss.weld.Weld.unsatisfiedBeanManager(Weld.java:99)
at org.jboss.weld.servlet.StaticWeldProvider$EnhancedWeld.unsatisfiedBeanManager(StaticWeldProvider.java:43)
at org.jboss.weld.Weld$ClassNameToBeanManager.findBeanManager(Weld.java:76)
at org.jboss.weld.Weld$ClassNameToBeanManager.apply(Weld.java:55)
at org.jboss.weld.Weld$ClassNameToBeanManager.apply(Weld.java:48)
at com.google.common.collect.ComputingConcurrentHashMap$ComputingValueReference.compute(ComputingConcurrentHashMap.java:358)
at com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.compute(ComputingConcurrentHashMap.java:184)
at com.google.common.collect.ComputingConcurrentHashMap$ComputingSegment.getOrCompute(ComputingConcurrentHashMap.java:153)
at com.google.common.collect.ComputingConcurrentHashMap.getOrCompute(ComputingConcurrentHashMap.java:69)
at com.google.common.collect.ComputingConcurrentHashMap$ComputingMapAdapter.get(ComputingConcurrentHashMap.java:396)
... 50 more

WARNING: java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: com.google.common.collect.ComputationException: org.jboss.weld.exceptions.IllegalStateException: WELD-001328 Unable to identify the correct BeanManager. The calling class org.jboss.weld.servlet.WeldListener is not placed in bean archive
java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: com.google.common.collect.ComputationException: org.jboss.weld.exceptions.IllegalStateException: WELD-001328 Unable to identify the correct BeanManager. The calling class org.jboss.weld.servlet.WeldListener is not placed in bean archive
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:1044)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:1024)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:747)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:2291)
at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1937)
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:139)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:497)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1761)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:534)
at com.sun.enterprise.v3.admin.AdminAdapter.onMissingResource(AdminAdapter.java:224)
at org.glassfish.grizzly.http.server.StaticHttpHandler.service(StaticHttpHandler.java:297)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:722)

SEVERE: Exception while invoking class com.sun.enterprise.web.WebApplication start method
java.lang.Exception: java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: com.google.common.collect.ComputationException: org.jboss.weld.exceptions.IllegalStateException: WELD-001328 Unable to identify the correct BeanManager. The calling class org.jboss.weld.servlet.WeldListener is not placed in bean archive
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:168)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:497)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1761)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:534)
at com.sun.enterprise.v3.admin.AdminAdapter.onMissingResource(AdminAdapter.java:224)
at org.glassfish.grizzly.http.server.StaticHttpHandler.service(StaticHttpHandler.java:297)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:722)

SEVERE: Exception during lifecycle processing
java.lang.Exception: java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: com.google.common.collect.ComputationException: org.jboss.weld.exceptions.IllegalStateException: WELD-001328 Unable to identify the correct BeanManager. The calling class org.jboss.weld.servlet.WeldListener is not placed in bean archive
at com.sun.enterprise.web.WebApplication.start(WebApplication.java:168)
at org.glassfish.internal.data.EngineRef.start(EngineRef.java:122)
at org.glassfish.internal.data.ModuleInfo.start(ModuleInfo.java:291)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:352)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:497)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:527)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:523)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:522)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:546)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1423)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1500(CommandRunnerImpl.java:108)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1761)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1674)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:534)
at com.sun.enterprise.v3.admin.AdminAdapter.onMissingResource(AdminAdapter.java:224)
at org.glassfish.grizzly.http.server.StaticHttpHandler.service(StaticHttpHandler.java:297)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:246)
at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
at java.lang.Thread.run(Thread.java:722)

SEVERE: Exception while loading the app
SEVERE: Undeployment failed for context /websockets-demo
SEVERE: Exception while loading the app : java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: com.google.common.collect.ComputationException: org.jboss.weld.exceptions.IllegalStateException: WELD-001328 Unable to identify the correct BeanManager. The calling class org.jboss.weld.servlet.WeldListener is not placed in bean archive



 Comments   
Comment by jjsnyder83 [ 11/Apr/13 ]

I am unable to open the zip. Can you email it to me: j.j.snyder@oracle.com

Comment by shreedhar_ganapathy [ 19/Apr/13 ]

Was this issue reproducible?
Could you update with latest status?

Comment by arjavdesai [ 19/Apr/13 ]

The app had an issue i.e. jms resource used by app is not defined by default. After adding that, I can deploy fine using admin console. Then I click on "redeploy" next to app-name in admin console (i.e. without undeploying first) and it works fine as seen in server logs

[2013-04-19T12:45:28.086-0400] [glassfish 4.0] [WARNING] [] [org.jboss.weld.Bootstrap] [tid: _ThreadID=140 _ThreadName=admin-listener(6)] [timeMillis: 1366389928086] [levelValue: 900] [[
  WELD-001473 javax.enterprise.inject.spi.Bean implementation org.glassfish.jms.injection.JMSCDIExtension$LocalBean@5ce4d7e declared a normal scope but does not implement javax.enterprise.inject.spi.PassivationCapable. It won't be possible to inject this bean into a bean with passivating scope (@SessionScoped, @ConversationScoped). This can be fixed by assigning the Bean implementation a unique id by implementing the PassivationCapable interface.]]

[2013-04-19T12:45:28.194-0400] [glassfish 4.0] [INFO] [] [org.glassfish.tyrus.servlet.TyrusServletContainerInitializer] [tid: _ThreadID=140 _ThreadName=admin-listener(6)] [timeMillis: 1366389928194] [levelValue: 800] [[
  Registering WebSocket filter for url pattern /*]]

[2013-04-19T12:45:28.221-0400] [glassfish 4.0] [INFO] [jsf.config.listener.version] [javax.enterprise.resource.webcontainer.jsf.config] [tid: _ThreadID=140 _ThreadName=admin-listener(6)] [timeMillis: 1366389928221] [levelValue: 800] [[
  Initializing Mojarra 2.2.0 (-SNAPSHOT 20130412-2121 https://svn.java.net/svn/mojarra~svn/tags/2.2.0-m14@11878) for context '/websockets-demo-1.0-SNAPSHOT']]

[2013-04-19T12:45:28.821-0400] [glassfish 4.0] [INFO] [AS-WEB-GLUE-00172] [javax.enterprise.web] [tid: _ThreadID=140 _ThreadName=admin-listener(6)] [timeMillis: 1366389928821] [levelValue: 800] [[
  Loading application [websockets-demo-1.0-SNAPSHOT] at [/websockets-demo-1.0-SNAPSHOT]]]

[2013-04-19T12:45:28.871-0400] [glassfish 4.0] [INFO] [] [javax.enterprise.system.core] [tid: _ThreadID=140 _ThreadName=admin-listener(6)] [timeMillis: 1366389928871] [levelValue: 800] [[
  websockets-demo-1.0-SNAPSHOT was successfully deployed in 6,677 milliseconds.]]

[2013-04-19T12:46:04.369-0400] [glassfish 4.0] [SEVERE] [] [javax.enterprise.web.util] [tid: _ThreadID=43 _ThreadName=admin-listener(3)] [timeMillis: 1366389964369] [levelValue: 1000] [[
  The web application [/websockets-demo-1.0-SNAPSHOT] created a ThreadLocal with key of type [org.glassfish.pfl.dynamic.codegen.impl.CurrentClassLoader$1] (value [org.glassfish.pfl.dynamic.codegen.impl.CurrentClassLoader$1@144e0fa3]) and a value of type [org.glassfish.web.loader.WebappClassLoader] (value [WebappClassLoader (delegate=true; repositories=WEB-INF/classes/)]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.]]

[2013-04-19T12:46:04.892-0400] [glassfish 4.0] [INFO] [] [javax.enterprise.system.tools.deployment.common] [tid: _ThreadID=43 _ThreadName=admin-listener(3)] [timeMillis: 1366389964892] [levelValue: 800] [[
  visiting unvisited references]]

[2013-04-19T12:46:05.069-0400] [glassfish 4.0] [INFO] [] [javax.enterprise.system.tools.deployment.common] [tid: _ThreadID=43 _ThreadName=admin-listener(3)] [timeMillis: 1366389965069] [levelValue: 800] [[
  visiting unvisited references]]

[2013-04-19T12:46:05.083-0400] [glassfish 4.0] [INFO] [] [javax.enterprise.system.tools.deployment.common] [tid: _ThreadID=43 _ThreadName=admin-listener(3)] [timeMillis: 1366389965083] [levelValue: 800] [[
  visiting unvisited references]]

[2013-04-19T12:46:05.090-0400] [glassfish 4.0] [INFO] [] [javax.enterprise.system.tools.deployment.common] [tid: _ThreadID=43 _ThreadName=admin-listener(3)] [timeMillis: 1366389965090] [levelValue: 800] [[
  visiting unvisited references]]

[2013-04-19T12:46:05.091-0400] [glassfish 4.0] [INFO] [] [javax.enterprise.system.tools.deployment.common] [tid: _ThreadID=43 _ThreadName=admin-listener(3)] [timeMillis: 1366389965091] [levelValue: 800] [[
  visiting unvisited references]]

[2013-04-19T12:46:05.093-0400] [glassfish 4.0] [INFO] [] [javax.enterprise.system.tools.deployment.common] [tid: _ThreadID=43 _ThreadName=admin-listener(3)] [timeMillis: 1366389965093] [levelValue: 800] [[
  visiting unvisited references]]

[2013-04-19T12:46:05.095-0400] [glassfish 4.0] [INFO] [] [javax.enterprise.system.tools.deployment.common] [tid: _ThreadID=43 _ThreadName=admin-listener(3)] [timeMillis: 1366389965095] [levelValue: 800] [[
  visiting unvisited references]]

[2013-04-19T12:46:05.170-0400] [glassfish 4.0] [INFO] [endpoint.determine.destinationtype] [javax.enterprise.resource.jms.com.sun.enterprise.connectors.jms.system] [tid: _ThreadID=43 _ThreadName=admin-listener(3)] [timeMillis: 1366389965170] [levelValue: 800] [[
  JMS013: Assuming destination type javax.jms.Queue for MDB MessageReceiverSync from administered object jms/myQueue]]

[2013-04-19T12:46:05.680-0400] [glassfish 4.0] [WARNING] [] [org.jboss.weld.Bootstrap] [tid: _ThreadID=43 _ThreadName=admin-listener(3)] [timeMillis: 1366389965680] [levelValue: 900] [[
  WELD-001473 javax.enterprise.inject.spi.Bean implementation org.glassfish.jms.injection.JMSCDIExtension$LocalBean@ccb68b4 declared a normal scope but does not implement javax.enterprise.inject.spi.PassivationCapable. It won't be possible to inject this bean into a bean with passivating scope (@SessionScoped, @ConversationScoped). This can be fixed by assigning the Bean implementation a unique id by implementing the PassivationCapable interface.]]

[2013-04-19T12:46:05.711-0400] [glassfish 4.0] [INFO] [] [org.glassfish.tyrus.servlet.TyrusServletContainerInitializer] [tid: _ThreadID=43 _ThreadName=admin-listener(3)] [timeMillis: 1366389965711] [levelValue: 800] [[
  Registering WebSocket filter for url pattern /*]]

[2013-04-19T12:46:05.744-0400] [glassfish 4.0] [INFO] [jsf.config.listener.version] [javax.enterprise.resource.webcontainer.jsf.config] [tid: _ThreadID=43 _ThreadName=admin-listener(3)] [timeMillis: 1366389965744] [levelValue: 800] [[
  Initializing Mojarra 2.2.0 (-SNAPSHOT 20130412-2121 https://svn.java.net/svn/mojarra~svn/tags/2.2.0-m14@11878) for context '/websockets-demo']]

[2013-04-19T12:46:05.937-0400] [glassfish 4.0] [INFO] [AS-WEB-GLUE-00172] [javax.enterprise.web] [tid: _ThreadID=43 _ThreadName=admin-listener(3)] [timeMillis: 1366389965937] [levelValue: 800] [[
  Loading application [websockets-demo-1.0-SNAPSHOT] at [/websockets-demo]]]

[2013-04-19T12:46:06.021-0400] [glassfish 4.0] [INFO] [] [javax.enterprise.system.core] [tid: _ThreadID=43 _ThreadName=admin-listener(3)] [timeMillis: 1366389966021] [levelValue: 800] [[
  websockets-demo-1.0-SNAPSHOT was successfully deployed in 1,740 milliseconds.]]

Now for netbeans part, I imported the zip file as project and bound it to my local glass fish. All, I could see in option was Run which tried to deploy the app and failed as it was already deployed. How are you doing deploy/re-deploy from within netbeans?

Comment by arjavdesai [ 22/Apr/13 ]

Can you please provide us with reproducible steps?

Comment by arjavdesai [ 22/Apr/13 ]

Changing the priority as its working from admin console while netbeans integration might have issue, if any.





[GLASSFISH-20025] Classloading needs to be optimized for the implicit CDI enablement functionality Created: 25/Mar/13  Updated: 19/Sep/14  Resolved: 24/May/13

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: 4.0_b83
Fix Version/s: 4.1

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


 Description   

For implicitly-enabled CDI apps, only those classes annotated with bean-defining annotations should be loaded at deployment-time, for performance reasons. Currently, there is logic to identify these bean classes, but all classes in the archive are still being loaded.



 Comments   
Comment by phil.zampino [ 24/May/13 ]

Committed revision 62100.
Updated weld-integration/src/main/java/org/glassfish/weld/BeanDeploymentArchiveImpl.java





[GLASSFISH-19429] CDI integration does not handle properly beans.xml files from library JAR Created: 11/Dec/12  Updated: 19/Sep/14  Resolved: 05/Mar/13

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: 3.1.2
Fix Version/s: 4.1

Type: Bug Priority: Major
Reporter: win_wave Assignee: jjsnyder83
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 7 x64, Java Oracle jdk1.7.0_03


Tags: beans, cdi, jar

 Description   

If you enable Decorator (may be also Interceptors, Alternatives) in beans.xml in JAR, which included to WAR application package, it Glassfish does not enable them properly (at least Decorators for sure).
If uses only "first" beans.xml file from the resources, even if you have several JARs. By CDI specs, we should enable decorator at least in one bundle, to make it enabled.
Structure of WAR:

  • WEB-INF/beans.xml
  • lib1.jar
    • MEAT-INF/beans.xml <-- here we enable decorator A
    • classes...
  • lib2.jar
    • MEAT-INF/beans.xml <-- here we enable decorator B
    • classes...
      Result: Only decorator A will be loaded!!

Problem in code:
org.glassfish.weld.BeanDeploymentArchiveImpl (org.glassfish.main.web:weld-integration:jar:3.1.2)
line 503:
URL beansXmlUrl = Thread.currentThread().getContextClassLoader().getResource(entry); <-- here is entry variable, which is always "META-INF/beans.xml", that makes wUris.add(beansXmlUrl.toURI()); context loader return always the same resource file

there are exists already "proper" way of loading beans.xml, it used to load WEB-INF/beans.xml from WAR:
line 352:
URI uri = archive.getURI();
File file = new File(uri.getPath() + entry);
URI beansXmlUri = file.toURI();
wUris.add(beansXmlUri);

I think, the same way should be implemented to load META-INF/beans.xml from JARs

WORKAROUND:

I've found solution, which is not complient, but at least works for now.
I need to have such structure:

  • WEB-INF/beans.xml
  • lib1.jar
    • MEAT-INF/beans.xml <-- leave that empty
    • WEB-INF/beans.xml <-- here we enable decorator A
    • classes...
  • lib2.jar
    • MEAT-INF/beans.xml <-- leave that empty
    • WEB-INF/beans.xml <-- here we enable decorator B
    • classes...


 Comments   
Comment by win_wave [ 11/Dec/12 ]

Actually workaround does not work. It was working in Eclipse, it was deploying open projects as folders, and properly found all resources. In case of jar package it fails to properly construct path to beans.xml

Comment by win_wave [ 11/Dec/12 ]

The working workaround is: Identify library which is "first", and add to it's beans.xml all required info about registration.
How to identify "first" library: I think, it is identified by alphabetical order. In order to be sure you can add comment into beans.xml like <!-- my lib 1--> into all libraries and after see into folder <domain_folder>\generated\<WAR_APP_NAME>\loader_<SOME_NUMBER>\META-INF\beans.xml, and check what comment it contains.

Actually that bug, "enables" possibility to configure CDI interceptors independently of the libraries. So it is possible to create library like "_configure.jar" which will contain all configurations.

Also figured out, that this issue is duplicate for http://java.net/jira/browse/GLASSFISH-18802

Comment by jjsnyder83 [ 05/Mar/13 ]

Duplicate of http://java.net/jira/browse/GLASSFISH-18802





[GLASSFISH-18827] Exception on app deployment if javassist bundled Created: 22/Jun/12  Updated: 19/Sep/14  Resolved: 25/Jul/13

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: 3.1.2
Fix Version/s: 4.1

Type: Bug Priority: Blocker
Reporter: arothe Assignee: phil.zampino
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OpenSuse 12.1
Glassfish 3.1.2 local installation


Tags: exception, javassist, weld

 Description   

I try to deploy an application, which has a maven dependency to javassist 3.14.0-GA. If I bundle the lib with the application I will get
Exception while loading the app : org.jboss.weldx.transaction.UserTransaction$1279195191$Proxy$_$$_Weld$Proxy$ cannot be cast to javassist.util.proxy.ProxyObject

If I set the maven scope to "provided", I will get
java.lang.NoClassDefFoundError: javassist/bytecode/CodeAttribute$RuntimeCopyException

The application uses CDI and EclipseLink as persistence provider.
I have seen, that javassist is already part of the weld-osgi-bundle, but the jar isn't used by the application.



 Comments   
Comment by arjavdesai [ 13/Apr/13 ]

Can you please provide a test app to re-produce the issue? Have tried with latest glass fish? If not, can you please try with one built on 13-apr-13 or later from http://dlc.sun.com.edgesuite.net/glassfish/4.0/nightly/.

Comment by arothe [ 05/Jun/13 ]

I have checked the old project on SVN. In the sun-web.xml I had an entry

<class-loader delegate="false"/>

The error didn't longer occur after removing that line. I'm not sure which influence the line has...





Generated at Fri Sep 30 21:59:34 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.