[GLASSFISH-21163] Include ../modules/cdi-api.jar in the Class-Path: section of META-INF/MANIFEST.MF in ${com.sun.aas.installRoot}/lib/javaee.jar Created: 12/Aug/14  Updated: 24/Mar/15

Status: Open
Project: glassfish
Component/s: cdi
Affects Version/s: 4.1
Fix Version/s: future release

Type: Bug Priority: Minor
Reporter: rgoldberg Assignee: Romain Grécourt
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 5 minutes
Time Spent: Not Specified
Original Estimate: 5 minutes
Environment:

All


Tags: cdi, jar, javaee, manifest, modules

 Description   

The:

Class-Path:

section of the file:

META-INF/MANIFEST.MF

in the jar file:

$

{com.sun.aas.installRoot}

/lib/javaee.jar

should include:

../modules/cdi-api.jar

Other Java EE jars might be missing from that manifest, too, but I haven't checked.



 Comments   
Comment by rgoldberg [ 12/Aug/14 ]

In the Description, I forgot to escape the opening brace and closing brace, so .${com.sun.aas.installRoot}/lib/javaee.jar is formatted poorly.

I cannot seem to edit the Description.

Can someone escape the braces?

Comment by rgoldberg [ 25/Aug/14 ]

Will this be fixed anytime soon?

It should only take 30 seconds to add ../modules/cdi-api.jar to the Class-Path: section.

It might take a few minutes (around 2 - 5) to check if any other jars should also be included.





[GLASSFISH-20413] automate jms resource creation for weld glassfish tck runner Created: 25/Apr/13  Updated: 11/Sep/14

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

Type: Bug Priority: Major
Reporter: jjsnyder83 Assignee: phil.zampino
Resolution: Unresolved 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 [ 25/Apr/13 ]

The arquillian.xml property, in this case, allow for a , separated list of resource file references. Tho I'm pretty sure you could define two jms resources in one resource.xml file as well.





[GLASSFISH-20371] Can't listen to JMS Queue from a WebSocket Created: 22/Apr/13  Updated: 22/May/13  Resolved: 22/May/13

Status: Resolved
Project: glassfish
Component/s: cdi
Affects Version/s: 4.0_b83
Fix Version/s: future release

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


 Description   

It should be possible to connect a WebSocket and a JMS queue using standards. The usecase is based on the idea where each websocket session will be a subscriber to a Topic. In this example specifically, code is based on a WebSocket session consuming a Queue.

It is possible to inject a JMSContext inside a WebSocket using @Inject at constructor [1], but whenever I try to inject a Queue/Topic, it does not get injected using @Resource [2].

Also tried to use JMS 1.1 code (creating a InitialContext, doing lookup on ConnectionFactory, etc), it dit not work.

Most of the time, I get this error [3].

MyWebSocket.java
@Named // with @Named or without, nothing from CDI works as it should
@ServerEndpoint("/path")
public class MyWebSocket implements MessageListener {
  // @Inject at field level does not work
  private JMSContext jmsContext;

  @Resource(mappedName = "jms/myQueue") // [2] jms queue/topic does not get injected
  private Queue queue;

  @Inject // [1] at constructor, it works
  public MyWebSocket(JMSContext jmsc) {
    this.jmsContext = jmsc;
    ... // code to create a MessageListener
   jmsContext.createConsumer(queue).setMessageListener(this);
  }

  public void onMessage(Message m) {
    webSocketSession.getAsyncRemote().sendText(m.getBody(String.class));
  }

}


 Comments   
Comment by David Zhao [ 23/Apr/13 ]

Regarding to the injection into WebSocket, I observed the following behavior. Forwarding to CDI team to take a look.

1. If JMSContext is injected as a field of class, it is not available in constructor(is that expected?). But it is available in @OnMessage method, which is correct. It seems that @OnMessage method of WebSocket doesn't have a vaild transaction or request scope, so the behavior of JMSContext injection will be undefined in JMS 2.0 spec.

2. If JMSContext is injected at constructor, then it is available inside constructor.

3. The queue injected by @Resource is null in both constructor and @OnMessage method.

How does CDI sped define the scope of injection for WebSocket?

Comment by Bruno Borges [ 23/Apr/13 ]

David, some answers and questions to your comment

1.1 It cannot be available at constructor when injection is at field level. That's fine, and expected.

1.2 What would be the transaction/request scope of JMSContext when it is injected into a HttpServlet?

a. Should WebSockets support @ApplicationScoped/@SessionScoped annotations?

2. Works as it should

3. Most problematic issue so far

Comment by Bruno Borges [ 23/Apr/13 ]

Issue https://java.net/jira/browse/GLASSFISH-20255 might be related to this.

Comment by David Zhao [ 23/Apr/13 ]

Bruno,

Please refer to the urls for the scopes of JMSContext injection.

https://java.net/projects/jms-spec/pages/JMSContextScopeProposalsv4p2
https://java.net/projects/jms-spec/pages/JMSContextScopeProposalsv4p3

I shall leave other CDI questions to CDI team.

Comment by jjsnyder83 [ 23/Apr/13 ]

IIRC only @ApplicationScoped and @Dependent is available for WebSocket. @SessionScoped and @RequestScoped injection is not available as http sessions and http requests aren't valid in the web socket world.

I'm not sure about @Resource injection...Can you do a jndi lookup successfully for the queue "jms/myQueue" from within the web socket?

Comment by Bruno Borges [ 23/Apr/13 ]

Traditional lookup of Queue works, but creating a valid consumer using the injected JMSContext does not.

GF throws a SEVERE message error saying that there is no valid EE environment.

Comment by arjavdesai [ 23/Apr/13 ]

Can you please provide us with a test app or netbeans project, if available?

Comment by jjsnyder83 [ 23/Apr/13 ]

The "...no valid EE environment" means that the GF cdi code couldn't access JNDI because the JNDI environment has not been set correctly for the thread on which the code is running. Something similar to how the web container sets up the invocation manager must also be done by the WebSocket code on which the thread is running or the injection of resources will fail. See WebContainerListener.preInvoke and .postInvoke for an example.

Comment by dannycoward [ 23/Apr/13 ]

This we think relates to https://java.net/jira/browse/GLASSFISH-20375

I'll post more information while we test with the fix for that issue.

Comment by arjavdesai [ 25/Apr/13 ]

https://java.net/jira/browse/GLASSFISH-20375 is marked as resolved with 61589. Can you retry your scenario and update this JIRA?

Comment by Bruno Borges [ 25/Apr/13 ]

No, it did not work.

Got this warning, and worse: the WebSocket didn't even initialize.

WARNING: WELD-001473 javax.enterprise.inject.spi.Bean implementation org.glassfish.jms.injection.JMSCDIExtension$LocalBean@55118a0 
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.
Comment by jjsnyder83 [ 26/Apr/13 ]

You can ignore the warning for now. It does not affect this particular issue.

Comment by Bruno Borges [ 26/Apr/13 ]

The message wasn't appearing before, and now appears, and the WebSocket does not work when there's @Resource for queue + @Inject for JMSContext.

Comment by jjsnyder83 [ 26/Apr/13 ]

I have contacted JMS team about the warning. The problem that the warning is about would only happen during passivation which I don't believe is happening here.

Can you be more specific in your comment that "the WebSocket didn't even initialize?" Are you still seeing the "...no valid EE environment" message?

Comment by Bruno Borges [ 26/Apr/13 ]

That message does not appear, but websocket does not work either, without any error message

Comment by dannycoward [ 29/Apr/13 ]

Can we get the complete code for this failure Bruno ? The sample code above is neither complete nor a well-formed websocket. Thanks.

Comment by Bruno Borges [ 30/Apr/13 ]

Yeah, project published here: https://github.com/brunoborges/javaee7-jms-websocket-bug

Comment by Nigel Deakin [ 02/May/13 ]

I think your code is throwing exceptions which are not being logged. Please update all the callbacks in your code to add a catch block for RuntimeException, and write the exception and stack trace to the server log. This will make it easier to understand what is going wrong.

Comment by Bruno Borges [ 02/May/13 ]

Code changed to print any type of Exception.

Exception found:

SEVERE:   javax.jms.JMSRuntimeException: [C4306]: This method may not be called in a Java EE web or EJB container
	at com.sun.messaging.jmq.jmsclient.JMSConsumerImpl.setMessageListener(JMSConsumerImpl.java:261)
	at org.glassfish.javaee7wsjms.SampleWebSocket.onOpen(SampleWebSocket.java:45)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:601)
	at org.glassfish.tyrus.core.AnnotatedEndpoint.callMethod(AnnotatedEndpoint.java:431)
	at org.glassfish.tyrus.core.AnnotatedEndpoint.onOpen(AnnotatedEndpoint.java:468)
	at org.glassfish.tyrus.core.EndpointWrapper.onConnect(EndpointWrapper.java:446)
	at org.glassfish.tyrus.server.TyrusEndpoint.onConnect(TyrusEndpoint.java:146)
	at org.glassfish.tyrus.websockets.DefaultWebSocket.onConnect(DefaultWebSocket.java:122)
	at org.glassfish.tyrus.servlet.TyrusHttpUpgradeHandler.init(TyrusHttpUpgradeHandler.java:98)
	at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:777)

Exception thrown at SampleWebSocket.java:45

Comment by Bruno Borges [ 02/May/13 ]

I understand the message as part of

12.2. Restrictions on the use of JMS API in the Java EE web or EJB
container

But then I wonder how can WebSockets proactively send data to clients, triggered by asynchronous events.

Is it possible for example, to plug a JMS MessageListener with a WebSocket using CDI? Let's say an MDB producing CDI Events and the WebSocket server endpoint consuming that?

Comment by Bruno Borges [ 02/May/13 ]

I've coded a version using CDI Events.

This version demonstrates a specific bug: Can't send messages to a Queue from a WebSocket

SEVERE:   org.jboss.weld.context.ContextNotActiveException: WELD-001303 No active contexts for scope type javax.enterprise.context.RequestScoped
	at org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:667)
	at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:74)
	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:79)
	at org.glassfish.jms.injection.RequestedJMSContextManager$Proxy$_$$_WeldClientProxy.getType(Unknown Source)
	at org.glassfish.jms.injection.InjectableJMSContext.delegate(InjectableJMSContext.java:126)
	at org.glassfish.jms.injection.ForwardingJMSContext.createProducer(ForwardingJMSContext.java:61)
	at org.glassfish.javaee7wsjms.SampleWebSocket.onMessage(SampleWebSocket.java:62)

Branch published on GitHub using-cdi

Comment by jjsnyder83 [ 02/May/13 ]

The ContextNotActiveException you are seeing means that an @RequestScoped CDI-injected object was accessed outside of an active http request. More specifically the JMSContext's @RequestScoped delegate is being accessed in SampleWebSocket.onMessage() but there is no active http request. The CDI-injected JMSContext can only be accessed when there's an active http request or active global transaction. If it is accessed outside of these scopes (http request or global transaction) you will see this type of message.

Comment by Nigel Deakin [ 02/May/13 ]

That matches my own experiments. Your call to context.createConsumer was successful, which suggests that an injected JMSContext can be used in the @OnOpen callback. However you should be aware that as an injected JMSContext has @RequestScoped (when there is no transaction) any object created from it will become invalid when the request ends. So the JMSConsumer you create from it won't be usable after then.

However when I invoked your @OnMessage callback (modified to catch exceptions) I got a Weld error:

SEVERE:   org.jboss.weld.context.ContextNotActiveException: 
WELD-001303 No active contexts for scope type javax.enterprise.context.RequestScoped 

which suggests there is a restriction in using an injected JMSContext in the @OnMessage callback. That's an open issue.

However, as you saw, you also hit the restriction that you can't set a MessageListener in a Java EE environment (except the ACC). This restriction is not new and was in Java EE 6.

There is no restriction on consuming messages synchronously (using JMSConsumer.receive()), or in sending messages. But if you want to consume messages asynchronously you're expected to use a MDB.

I suggest moving discussion of your application design to email.

Comment by Bruno Borges [ 02/May/13 ]

I managed to make this work using CDI events. Still, some things had to be changed:

  1. It is impossible, as I understand from the spec, to connect WebSockets and JMS directly.
  2. To send an incoming message from a WebSocket client to a JMS queue, I used a @Stateless session bean
    There's still a bug in here, because it was not possible to @Inject the SB the normal way. Had to use constructor-injected parameter.
  3. SessionBean does use JMS 2 the way it is specified, @Inject JMSContext and @Resource Queue.
  4. @MessageDriven bean produces a CDI event with the JMS payload
  5. The WebSocket server endpoint @Observes for CDI event with the payload. Then payload is sent to all WebSocket sessions

The code is available here

Comment by Bruno Borges [ 02/May/13 ]

Although I'm happy that such integration is possible, I wonder if this could be simplified by JMS_SPEC-100

Comment by Bruno Borges [ 05/May/13 ]

Created two separate bugs that were found due to this issue:

Comment by jjsnyder83 [ 22/May/13 ]

Duplicate of https://java.net/jira/browse/JMS_SPEC-121





[GLASSFISH-19978] public enum classes log severe messages in server log Created: 21/Mar/13  Updated: 11/Apr/13  Resolved: 11/Apr/13

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

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

GlassFish Server Open Source Edition 4.0 (build 80)


Tags: fishcat

 Description   

Having two public enum types in my app leads to following log messages during deployment:

public enum Role {
JUNIOR,
PRINCIPAL,
SENIOR
}

INFO: Loading application [MissionControl] at [/MissionControl]
SEVERE: No valid EE environment for injection of net.eisele.mcontrl.entities.types.MissionState
SEVERE: No valid EE environment for injection of net.eisele.mcontrl.entities.types.MissionState
SEVERE: No valid EE environment for injection of net.eisele.mcontrl.entities.types.MissionState
SEVERE: No valid EE environment for injection of net.eisele.mcontrl.entities.types.Role
SEVERE: No valid EE environment for injection of net.eisele.mcontrl.entities.types.MissionState
SEVERE: No valid EE environment for injection of net.eisele.mcontrl.entities.types.MissionState
SEVERE: No valid EE environment for injection of net.eisele.mcontrl.entities.types.MissionState
SEVERE: No valid EE environment for injection of net.eisele.mcontrl.entities.types.MissionState
SEVERE: No valid EE environment for injection of net.eisele.mcontrl.entities.types.MissionState
SEVERE: No valid EE environment for injection of net.eisele.mcontrl.entities.types.Role
SEVERE: No valid EE environment for injection of net.eisele.mcontrl.entities.types.Role
SEVERE: No valid EE environment for injection of net.eisele.mcontrl.entities.types.MissionState
INFO: MissionControl was successfully deployed in 1.546 milliseconds.



 Comments   
Comment by tlcksnyder [ 21/Mar/13 ]

Please provide a test case, or explain further as to why you feel this is a CDI issue. We cannot investigate without more information and a test case.





[GLASSFISH-19759] Support binding to OSGi services at deploy-time Created: 01/Mar/13  Updated: 25/Mar/13

Status: Open
Project: glassfish
Component/s: cdi, OSGi-JavaEE
Affects Version/s: None
Fix Version/s: future release

Type: Improvement Priority: Minor
Reporter: Sivakumar Thyagarajan Assignee: Sivakumar Thyagarajan
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: future-release, osgi-cdi, osgi-javaee

 Description   

Today the osgi-cdi portable extension supports the injection of OSGi Services into injection points marked with a custom OSGi Qualifier @OSGiService. Unfortunately this binds application components that reference these Services at deployment time to OSGi. There could be scenarios where the determination that a Service being injected is an OSGi Service, can be made at deployment-time based on the environment that the application component is part of. It would be good if we have the ability for a client of an OSGi Service to indicate that the Service is an OSGi Service at deploy-time.



 Comments   
Comment by Sivakumar Thyagarajan [ 01/Mar/13 ]

One approach to consider is providing a capability to a deployer (through a custom deployment-descriptor) to specify that a particular injection point is an OSGi Service injection point, and have the osgi-cdi portable extension read this descriptor and automatically add the @OSGiService qualifier at runtime.

Comment by TangYong [ 01/Mar/13 ]

Siva,

The capability is very important while combining PaaS model, and in PaaS, ServiceType can be extended into OSGi Service, then, an user can specify an OSGi Service as some PaaS Service in liking glassfish-services.xml.

Then, by discovering OSGi Service engine(to be implemented in the future), these OSGi Services meeting the user's requirements will be injected into client at runtime.

Tang

Comment by TangYong [ 25/Mar/13 ]

Seeing siva's said carefully, Siva's means should be following,

[Current OSGi/CDI portable extension]
Class A

{ @OSGiService B b ... }

The issue should wish to remove @OSGiService instead still using @Inject and adding some way to tell deployment to automatically determinate b is a OSGi Service.

Then, if using a custom deployment-descriptor, this is similar to Declarative Services, OK, let us to see this will bring what advantage?

Imaging a scene that some user has written a application which uses common cdi with well-designed interface, however, while he/she wants to switch another B's implementation and does not change any consumer's source, by this feature, he/she should implement.

Comment by Sivakumar Thyagarajan [ 25/Mar/13 ]

Yes, Tang.

The idea is to support the following:

  • Allow the development of POJOs and dependency injection not knowing during development time that a particular injection point would be satisfied through an OSGi Service. So in the above example, the application includes a POJO
    Class A { @Inject StockQuoteService b; }
  • At deployment time, we should allow the deployer to override the injection and indicate that the injection point A.b is an OSGi Service injection and provide the details through a custom deployment-descriptor. For instance here is a rough idea on how a deployer could state that the injectin point A.b is an OSGi Service.
    glassfish-osgi-cdi.xml:
    <osgi-service dynamic="true">
    <managed-bean name="A">
    <attribute name ="b"/>
    </managed-bean>
    </osgi-service>
  • The osgi-cdi portable extension must read this optional custom deployment-descriptor, and automatically at deployment time, make A.b have a qualified @OSGiService.

Does this help? All the above details are just ideas at this point in time. Let us evaluate how best to resolve this.





[GLASSFISH-19572] Simplify exporting of com.sun.ejb.containers.interceptors from ejb-container Created: 23/Jan/13  Updated: 14/Aug/13  Resolved: 12/Aug/13

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: 4.0_b68_EE7MS3
Fix Version/s: future release

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   

A CDI tck test was failing because ejb interceptors not visible to cdi module. I exported the entire com.sun.ejb.containers.interceptors package but it may not be necessary to export the entire package.



 Comments   
Comment by jjsnyder83 [ 23/Jan/13 ]

Committed revision 58766

Comment by jjsnyder83 [ 23/Jan/13 ]

Find the tck test that fails so that we can investigate further. We might want to add an interface or move things around. It's not the best choice to export the whole package at once.

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

I tried removing the export that was added via rev. 58766, but I can't reproduce any CDI TCK failures with this change.

Comment by phil.zampino [ 12/Aug/13 ]

Committed rev. 62498





[GLASSFISH-18823] Dynamic injection of custom properties Created: 22/Jun/12  Updated: 12/Aug/13  Resolved: 18/Jun/13

Status: Closed
Project: glassfish
Component/s: cdi
Affects Version/s: 3.1.1_b12
Fix Version/s: future release

Type: Improvement Priority: Minor
Reporter: mkarg Assignee: phil.zampino
Resolution: Won't Fix Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

GF3.1.1 Win7 Pro SP1 (64 Bit) JDK 1.6.0_26



 Description   

Sometimes there is a need to modify properties at runtime, i. e. modifying business level application behaviour changes without restarting the domain. This makes sense for example in public services where a planned outage is not wanted.

This can be done in GF3.1.1 by using custom properties which are looked up using JNDI code.

But JNDI is not as smart as CDI, so one wishes to get injection instead. While the injection works, it is static. This means, the change will not get reflected until a domain restart.

We would be really glad if this would work dynamically, i. e. a modification of a custom property would inject at once without the need to restart the domain or the need to use JNDI code.



 Comments   
Comment by jthoennes [ 04/Jul/12 ]

Hello, is this feasible to be implemented?

Comment by marina vatkina [ 05/Jul/12 ]

I'm not sure if the solution is to be in naming or CDI. Let's start with naming

Comment by Cheng Fang [ 12/Jul/12 ]

Since it works with custom resource lookup, have you tried adding an additional proxy or container custom resource, which looks up the dynamic value of the first resource?

You can inject the proxy resource into your application as usual. But this requires that class to be available to server runtime (outside your application packaging) and thus complicates application configuration.

CDI has a Provider type (http://docs.oracle.com/javaee/6/api/index.html?javax/inject/Provider.html), not sure if it can be configured for the dynamic values.

Comment by mkarg [ 13/Jul/12 ]

Maybe you misunderstood why I suggested this feature: I want to get rid of using JNDI. If I am using CDI to write a provider as you suggested, that provider in turn has to use JNDI again. So what did I win? Just even more work and a much complexer solution. But the target is to have LESS work and REDUCE complexity. So CDI certainly will remove JNDI from my bean, but it will simply move it to another bean.

Comment by Cheng Fang [ 13/Jul/12 ]

It's the spec requirement that injection happens only once for the entire life of a component,and it happens at the beginning of its lifecycle. If you want dynamic values, it will need to be implmented by your custom resource type, e.g., via lookup.

Comment by Cheng Fang [ 13/Jul/12 ]

Transfer to cdi for evaluation.

Comment by mkarg [ 16/Jul/12 ]

This might be true for completely selfdeveloped custom types, but it could be implemented into that types that GlassFish ships with already. That means, the fact that CDI forces one-time injection does not prevent the GlassFish-custom-types from working dynamically inside themselves.

Comment by jjsnyder83 [ 29/Oct/12 ]

Could you provide an example of what you want?

Comment by mkarg [ 08/Dec/12 ]

Here is an example scenario:

An EAR-packaged application might need to have a switch that enables or disabled one particular business process (like a boolean for "this feature is enabled"). For example, the process could be that data is to be synchronized between the application and an external data source or sink (like another external application). If the EAR-customer also runs that external application, he switches this sync feature on (if he likes). Otherwise, he switches this feature off (= the default).

Possibly, the EAR-packaged application is used 24x7, and he wants to switch on the sync feature, there is no time to shutdown the container to trigger a CDI-reinjection of the boolean. But to simplify coding, the EAR-vendor does not like to use JNDI (which would be "live"). So my proposal to get "live" values in CDI would be that GlassFish for this reason comes with an implementation of custom properties that are injectable, but that will update "live" under the hood.

Here is how GlassFish could do that:

A solution could be that the static instance (here: boolean value) that is getting CDI-injected is a dynamic wrapper around JNDI but not just a Java primitive. This means, PrimitivesAndStringFactory will in fact not provide a copy of primitive value (boolean), but a reference (hence, java.lang.Boolean), where the reference is always the same but simply either points to the customized value or uses DynamicProxy API, ASM API, or whatever tweak to get a dynamic resolution of the value (e. g. using JNDI internally). That reference is statically injected, but as it is not a copy but a "living" object, it will dynamically reflect any value changes "live".

Example:

@Inject Boolean myValue; // GlassFish injects an object that looks like a Boolean but actually will use JNDI to always return the latest "live" value when any of java.lang.Boolean's methods are invokes.

A different solution could be that CDI injects at the moment the EJB component is getting from the pool instead of when being constructed. That way, a GlassFish factory could simply lookup the value each time the factory is triggered, hence, every time the EJB is taken out of the pool.

Comment by jjsnyder83 [ 18/Jun/13 ]

I think what you're looking for is a portable extension that defines beans for properties. The bean implementations either use jndi, jmx, or something else to lookup the value of the property each time it's accessed. Please check DeltaSpike to see if someone has already written an extension to do this.

CDI requires a scope for objects that it manages so that it knows when to create a new instance under the covers (anything but @Dependent is proxied so that when the injected proxy is access CDI can get the correct instance based on the scope of the injected object.)





[GLASSFISH-18514] CDI does not get enabled on server start for a WAB bundle, the war has to be redeployed after the server starts for CDI to be enabled. Created: 15/Mar/12  Updated: 20/Mar/13

Status: Open
Project: glassfish
Component/s: cdi, OSGi-JavaEE
Affects Version/s: 3.1.2
Fix Version/s: future release

Type: Bug Priority: Critical
Reporter: aaronjwhiteside Assignee: Sivakumar Thyagarajan
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File server.log    

 Description   

CDI does not get enabled on server start for a WAB bundle, the war has to be redeployed after the server starts for CDI to be enabled.

Please see attached server.log

You can see after the server has started I manually redeployed the WAB and CDI was enabled that time.

If I do not redeploy the WAB CDI is not enabled and I get NPE when trying to access a JAX-RS resource that @Inject's a @OSGiService(dynamic=true).



 Comments   
Comment by aaronjwhiteside [ 16/Mar/12 ]

So I think I tracked down the issue.

The org.glassfish.fighterfish.osgi-cdi bundle which provides the cdi support for WAB's has a run level of 2. However any bundle that is deployed under <domain>autodeploy/bundles always has a run level of 1.

So when you start glassfish that already has bundles under autodeploy/bundles and no osgi-cache (to tell it the deploy order, if you deployed something after the server was already started) it'll start the osgi-cdi bundle after the WAB bundle. And thus CDI support is never enabled for WAB's.

I tried adding

felix.fileinstall.start.level=4 

to glassfish3/glassfish/config/osgi.properties

But the bundles deployed from <domain>/autodeploy/bundles still seem to start in runlevel 1.

Comment by aaronjwhiteside [ 16/Mar/12 ]

For reference:
http://felix.apache.org/site/apache-felix-file-install.html

Comment by aaronjwhiteside [ 16/Mar/12 ]

OK so it turns out that all the felix.fileinstall* properties in osgi.properties are totally ignored and should probably be removed.

The real file doing the configuration is:

glassfish3/glassfish/modules/autostart/org.apache.felix.fileinstall-autodeploy-bundles.cfg

However if I add the line:

felix.fileinstall.start.level=4

to this file, it still does not set the run level for bundles under autodeploy/bundles, they still start at run level one.

However I do get a log message printed out:

[#|2012-03-15T20:08:20.322-0400|INFO|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=12;_ThreadName=Thread-2;|felix.fileinstall.start.level set, but not a int: 4 |#]

Which is interesting, apparently 4 really isn't an int.. I guess this is an ERROR even though it says INFO.. or maybe a WARN as it seems to have ignored the config.

Without this fixed OSGi is pretty much useless.

Comment by aaronjwhiteside [ 16/Mar/12 ]

Fixing this issue will probably fix another bug I reported too.

http://java.net/jira/browse/GLASSFISH-18508

And a bunch of other random weird stuff I was pulling my hair out over..

Comment by aaronjwhiteside [ 16/Mar/12 ]

OK so after more investigation it turns out you have to set:

felix.fileinstall.start.level=4

in osgi.properties AND org.apache.felix.fileinstall-autodeploy-bundles.cfg or less it does not get picked up. This is probably a bug too.

(and obviously, even through I omitted it you must set glassfish.osgi.start.level.final=4 in osgi.properties too).

So now I can see that the start level of my WAB bundle is really 4, however CDI still does NOT get enabled. I have to remove the war and redeploy it again, after the server has started for CDI to kicked in.

So my assumption that the start level's were the issue seems to be moot, however having a start level of 1 for the bundles under autodeploy/bundles and a start level of 2 for most of glassfish's osgi to jee integration bundles is still a bug. The bundles under autodeploy/bundles should start in start level 4.

So the question is now, if not start levels, what is causing CDI to not load and required a redeploy of the war to be enabled???

Comment by Sanjeeb Sahoo [ 16/Mar/12 ]

No, I don't understand some of your observations. This is how things are supposed to work:

no osgi-cache:
fileinstall is started at start level 2 and it is configured to start after modules/autostart/,
which means first time (same as no osgi cache) the server starts, fileinstall will come into effect
after all bundles in modules/autostart/. Once fileinstall is started, it will then go onto deploy
autodeploy/bundles/. Now, let's say one such bundle is a WAB that uses CDI.
Since osgi-cdi is already installed,when the WAB is processed, osgi-cdi will process the WAB as well.

Let's stop the server and restart. Upon restart, the WAB is started at start level 1 which means it is
started before osgi-web-container and osgi-cdi are started. But, the WAB processing is deferred until
osgi-web-container is started. When server reaches start level 2, osgi-web-container is started and it
processes the WAB. It does not matter whether osgi-cdi is active or not. It only has to be in INSTALLED
state for it to be useful. So, when the WAB is processed by osgi-web-container, osgi-cdi will be used
as well.

So, I don't see a case why osgi-cdi is not used in your case. Could you supply a test case with instructions?
I tried a WAB+CDI test case and could not reproduce.

A note about fileinstall start level:
The bundles in autodeploy/bundles/ are started at start level 1. This seems like
a bad configuration. They should have start level matching that of fileinstall, which is 2. I will
open a separate issue to do this. But, I can't see it affecting any functionality now.

To change the start level of bundles in autodeploy/bundles, edit osgi.properties file.
modules/autostart/o.a.f.fileinstall-autodeploy-bundles.cfg is not used any more.
If you set a start level higher than 2, then you must also configure the server to change the
start level to that value. Currently, server sets final start level to 2 using the property:
glassfish.osgi.start.level.final=2
Change it to the higher value, else your bundles in autodeploy/bundles will never get activated.

Comment by aaronjwhiteside [ 16/Mar/12 ]

After clearing the osgi-cache (I keep forgetting) CDI now works, so changing the start level fixed the issue.

Can this please be fixed in the next release?

Comment by Sanjeeb Sahoo [ 17/Mar/12 ]

What you want to be fixed? start level of bundles/autodeploy/? Sure it can be (could you file an issue under osgi category?), but, as I mentioned earlier, I don't understand why you had to change start level. Are you really sure things didn't work for you as is? I would love to understand it better. Do you have a reproducible test case?

Comment by tlcksnyder [ 20/Mar/13 ]

not attempting to fix without a reproducible test case, or better description of reproduction steps.





[GLASSFISH-15249] Support vanilla OSGi bundles as bean archives and Bean dependencies between bundles Created: 17/Dec/10  Updated: 16/Oct/12

Status: Open
Project: glassfish
Component/s: cdi, OSGi-JavaEE
Affects Version/s: None
Fix Version/s: future release

Type: New Feature Priority: Major
Reporter: Sivakumar Thyagarajan Assignee: Sivakumar Thyagarajan
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks GLASSFISH-15119 CDI Interceptor still not working in ... Open

 Description   

GF3.1 CDI-OSGi support should support scenarios where the Beans used by a bundle are in a different bundle, and scenarios where Beans could exist in plain vanilla osgi bundles.

See GLASSFISH-15119 for a discussion on this issue.



 Comments   
Comment by Sivakumar Thyagarajan [ 15/Oct/12 ]

Moving this to a future release. The immediate interest is to align with the OSGi/CDI RFC.

Comment by TangYong [ 15/Oct/12 ]

siva, sahoo

Pl. add osgi-javaee into Component/s.

Comment by Sivakumar Thyagarajan [ 16/Oct/12 ]

Adding osgi-javaee to the component list





[GLASSFISH-15119] CDI Interceptor still not working in OSGi Created: 12/Dec/10  Updated: 25/Mar/13

Status: Open
Project: glassfish
Component/s: cdi, OSGi-JavaEE
Affects Version/s: 3.1_b31
Fix Version/s: future release

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

Tested with promoted b32


Attachments: GZip Archive interceptor-osgi-test-2-fixed.tar.gz     GZip Archive interceptor-osgi-test-2.tar.gz     File interceptor-osgi-test.tar.bz2    
Issue Links:
Dependency
depends on GLASSFISH-15249 Support vanilla OSGi bundles as bean ... Open
Tags: 3_1-exclude, 3_1-next, 3_1_1-scrubbed

 Description   

I just revisited GLASSFISH-13513 and GLASSFISH-14831 to see if it is possible to plug in interceptors the CDI way around EJBs.

Indeed when deploying a prepared package as non-OSGi the interceptor gets invoked but not when using OSGi deployment.

Therefore I made up another test case which should be sufficient for a confirmation of this issue:

  • maven reactor build with 4 modules
  • build.sh script for test:
  • "mvn clean install"
  • copy resulting artifacts into .../autodeploy/bundles/ folder of a running glassfish domain
  • wait for (re-)deployment
  • using "curl" to call the web service
  • search for a fault inside the returned XML

So basically for a test I issue a command like this:

$ GF_DOMAIN_DIR=/srv/servers/gf-3.1-b32/glassfish/domains/domain1/ ./build.sh

Well, I also can say that with the old @Interceptors(

{SecurityInterceptor.class}

) method the interceptor is being called so I suspect it is not injected at all.

This test throws a fault if the interceptor is being invoked. If no fault occurs and the response is valid there must be something wrong.



 Comments   
Comment by chaoslayer [ 12/Dec/10 ]

Thanks for reopening the issue, I was not allowed to.

Comment by Sanjeeb Sahoo [ 14/Dec/10 ]

Assigning this to cdi team after talking to Siva. It is a bug in their layer.

Comment by chaoslayer [ 14/Dec/10 ]

Fixed the project and enabled interceptor class in beans.xml for the user service [interceptor-osgi-test-2-fixed.tar.gz].

Just tested again with a completely clean b32:

INFO: Portable JNDI names for EJB UserServiceImpl : [java:global/org.glassfish.cditest.user.service_2.0.0.SNAPSHOT/UserServiceImpl!org.glassfish.cditest.user.api.UserService, java:global/org.glassfish.cditest.user.service_2.0.0.SNAPSHOT/UserServiceImpl]
INFO: WELD-000900 $

{parsedVersion (osgiVersion}

)
INFO: Instantiated an instance of org.hibernate.validator.engine.resolver.JPATraversableResolver.
SEVERE: Exception while loading the app
INFO: Deleted /tmp/osgiapp5600363451663621402
SEVERE: Failed while deploying bundle org.glassfish.cditest.user.service [252]
WARNING: Failed to deploy bundle org.glassfish.cditest.user.service [252]
org.glassfish.osgijavaeebase.DeploymentException: Deployment of org.glassfish.cditest.user.service [252] failed because of following reason: Failed while deploying bundle org.glassfish.cditest.user.service [252] : java.lang.RuntimeException: Failed to deploy bundle [ org.glassfish.cditest.user.service [252] ], root cause: Exception while loading the app
at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:125)
at org.glassfish.osgijavaeebase.OSGiContainer.deploy(OSGiContainer.java:147)
at org.glassfish.osgijavaeebase.JavaEEExtender.deploy(JavaEEExtender.java:132)
at org.glassfish.osgijavaeebase.JavaEEExtender.handleEvent(JavaEEExtender.java:117)
at org.glassfish.osgijavaeebase.JavaEEExtender.access$000(JavaEEExtender.java:56)
at org.glassfish.osgijavaeebase.JavaEEExtender$1.run(JavaEEExtender.java:100)
Caused by: java.lang.RuntimeException: Failed to deploy bundle [ org.glassfish.cditest.user.service [252] ], 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)
... 5 more
Caused by: org.glassfish.deployment.common.DeploymentException: WELD-001417 Enabled interceptor class <class>org.glassfish.cditest.security.interceptor.SecurityInterceptor</class> in bundle://252.0:1/META-INF/beans.xml@8 is neither annotated @Interceptor nor registered through a portable extension
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:187)
at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:128)
at org.glassfish.internal.data.ApplicationInfo.start(ApplicationInfo.java:302)
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)
... 7 more
Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001417 Enabled interceptor class <class>org.glassfish.cditest.security.interceptor.SecurityInterceptor</class> in bundle://252.0:1/META-INF/beans.xml@8 is neither annotated @Interceptor nor registered through a portable extension
at org.jboss.weld.bootstrap.Validator.validateEnabledInterceptorClasses(Validator.java:471)
at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:344)
at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:383)
at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:184)
... 12 more

So I guess it has to do with class visibility here. Although all required classes are visible for the bundle it may once again be a deployment issue:

250|Active | 1|Apache Felix Bundle Repository (1.6.2)
251|Active | 1|OSGi/JTA implementation in GlassFish (3.1.0.b32)
252|Active | 1|User Service OSGi Bundle (2.0.0.SNAPSHOT)
253|Active | 1|User Web Service OSGi Web Service (2.0.0.SNAPSHOT)
254|Active | 1|security.impl OSGi Bundle (2.0.0.SNAPSHOT)
255|Active | 1|security.api OSGi Bundle (2.0.0.SNAPSHOT)
g! inspect p c 255
org.glassfish.cditest.security.api [255] exports packages:
----------------------------------------------------------
org.glassfish.cditest.security.api; version=0.0.0 imported by:
org.glassfish.cditest.user.service [252]
org.glassfish.cditest.security.impl [254]
g! inspect p c 254
org.glassfish.cditest.security.impl [254] exports packages:
-----------------------------------------------------------
org.glassfish.cditest.security.interceptor; version=0.0.0 imported by:
org.glassfish.cditest.user.service [252]
g! inspect p r 252
org.glassfish.cditest.user.service [252] imports packages:
----------------------------------------------------------
javax.ejb; version=3.1.0 -> org.glassfish.javax.ejb [171]
org.glassfish.cditest.security.interceptor; version=0.0.0 -> org.glassfish.cditest.security.impl [254]
org.glassfish.cditest.security.api; version=0.0.0 -> org.glassfish.cditest.security.api [255]

Comment by Sanjeeb Sahoo [ 14/Dec/10 ]

I discussed with our CDI engineer (sivakumar) and he thinks there is more to it than classloading. He thinks this can be reproduced without use of OSGi as well. He is looking into it.

Comment by chaoslayer [ 14/Dec/10 ]

OK, so do you need any additional data from my side?

Comment by Sanjeeb Sahoo [ 14/Dec/10 ]

No, not at this point. We have sufficient information to proceed. Thanks.

Comment by Sanjeeb Sahoo [ 15/Dec/10 ]

Needed for 3.1

Comment by Sivakumar Thyagarajan [ 17/Dec/10 ]

Modified testcase with the following changes:
1. brought the interceptor enablement to security.impl and 2. removed the interceptor enablement in user.impl

The interceptor class is defined in security.impl and must be enabled there.

Comment by Sivakumar Thyagarajan [ 17/Dec/10 ]

While debugging this issue, we noticed that the interceptor was enabled in the user.impl bundle. The interceptor is defined in the security.impl bundle and hence has to be enabled there. Attached the modified test-case that has these changes. With these changes, the 3 bundles deploy in GF3.1 latest trunk.

However there is an issue. GF3.1 considers the first two bundles (security.api and security.impl) as plain vanilla OSGi bundles (not EE archives) and hence are not considered as CDI archives. Furthermore, since there is no "explicit" relationship (apart from the usage of the CDI interceptor binding) between the user.impl and the other two bundles, when the user.impl WAB is deployed, the user.impl WAB "alone" is considered as a CDI archive. The CDI runtime does not have access to the Beans in security.api/security.impl and hence this usecase will not work. GF3.1 CDI-OSGi support should support scenarios where the Beans used by a bundle are in a different bundle and scenarios where Beans could exist in plain vanilla osgi bundles. I have raised a RFE, GLASSFISH-15249, for this and targetted this for 3.2 as it is more involved to be considered for 3.1.

Here are two possible workarounds:

  • One bundle: Bundling all the Beans together in user.impl (ie have one bundle and not 3 bundles) would work. I don't know if this works for you, though.
  • Fragment bundle approach: I had a discussion with Sahoo and he is investigating the use of security.api and security.impl as fragment bundles as a workaround, and he will update this thread with his finding.
Comment by Sivakumar Thyagarajan [ 17/Dec/10 ]

Raised a RFE GLASSFISH-15249 to fix the underlying usecase.

Comment by chaoslayer [ 17/Dec/10 ]

Well, not quite covering our use case scenario. Let me explain what we "want":

  • we have one Security API bundle that contains the @Secure interface
  • we have one or more Security implementation bundles that contain the implementation for @Secure
  • we have around 20 EJB bundles that have to be "secured" via the CDI interceptor binding

So workaround one effectively disables OSGi here completely and pulls in a lot of work todo for our setup, from building to integration testing to deployment.

Option two could be an option, although I think only the bundle that contains the interceptor should be made available as a fragment bundle attaching to all those EJB bundles.

But what happens if not all Fragement-Hosts are available for the interceptor fragment bundle? Is it still resolved for those that are available? The spec is somewhat unclear here. The use case here is of course modularity. As our developers are working in different areas of interest they only use the bundles that they need. Security is a very basic need but should support those scenarios without modification at build time.

Thanks for the RFE, btw.

Comment by Sanjeeb Sahoo [ 17/Dec/10 ]

Yes, I just tried by converting security.impl to be a fragment of user.impl and having the <interceptors> element defined in user.impl's beans.xml. With this, I am able to see the interceptors in action. I realize this is not an optimal solution, but looks like a work around to me.

Comment by Sanjeeb Sahoo [ 17/Dec/10 ]

A fragment can't be attached to more than one host, so there is a potential issue for your use case. Let us think more.

Comment by Sivakumar Thyagarajan [ 17/Dec/10 ]

Marking as "3_1-exclude" and targetting for 3.2

Comment by Sivakumar Thyagarajan [ 06/Jul/11 ]

Marking as 3_1-next as this was targetted for 3.1+ releases

Comment by Sivakumar Thyagarajan [ 08/Jul/11 ]

Marked issue as "Major"

Comment by Sivakumar Thyagarajan [ 15/Oct/12 ]

Moving a fix for this to a "future release" as the dependent issue GLASSFISH-15249 is also moved.

There is a workaround for this issue as Sahoo points out above.

Comment by TangYong [ 15/Oct/12 ]

siva, sahoo,

Please add a osgi-javaee component for the issue.

Comment by TangYong [ 25/Mar/13 ]

Because the bug depends on GLASSFISH-15249 which will be implemented in future release, fix version is adjusted into future release.





Generated at Sun Apr 19 01:41:51 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.